Opened 17 years ago

Last modified 17 years ago

#1177 closed Bug report

Windows (XP) Shortcuts not working

Reported by: whdconsultant Owned by:
Priority: normal Component: FileZilla Client
Keywords: Cc: whdconsultant, Tim Kosse
Component version: Operating system type:
Operating system version:


I'm pretty sure this used to work before 2.2.23. I am
currently using 2.2.28.

Now, when you click on a shortcut ("symlink") in the
LOCAL file list, instead of moving to that directory
(like it used to), it now opens up that directory in a
Windows directory view window. (I don't think it's even
a file explorer window -- is there a diff?)

Change History (3)

comment:1 by Tim Kosse, 17 years ago

Resolving of .lnk files was never implemented and won't be,
.lnk files are just normal files some other programs extract
some special semantics from.

comment:2 by whdconsultant, 17 years ago

Imo, that's pretty much unadulterated bullshite. Maybe you
don't care about Window's users, and don't care about
supporting them. But the way the Windows OS works is that
shortcuts work and are de-referenced. EVERY
(well-programmed) Win program supports this. Even *nix works
that way, and those symbolic links should also be
de-referenced. (in fact, they are and do work on my linux
server, and filezilla 'supports' that in the remote window)
And they DID work before at one point. (or I would have
mentioned this before) Maybe you didn't want to support
that, or it was inadvertent. And then some code must have
been modified.

comment:3 by Tim Kosse, 17 years ago

I know for sure it never worked, there never has been any
code in FZ client to handle .lnk files.

Real symlinks (as used under *nix) and .lnk files are
somethings very different.

I did the simple test and created a .lnk file, put it into
Then I opened up the the command prompt.

cd c:\test
cd link
"The system cannot find the path specified.

So this indicates, that .lnk support is not a native feature
of the filesystem layer.

Note: See TracTickets for help on using tickets.