Opened 18 years ago
Last modified 18 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: |
Description
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 , 18 years ago
comment:2 by , 18 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 , 18 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
c:\test\link.lnk.
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.
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.