Opened 15 years ago
Closed 15 years ago
#3928 closed Bug report (worksforme)
Symbolic links cached and not refreshed
|Reported by:||tonyg||Owned by:|
|Keywords:||link ln softlink symbolic||Cc:|
|Component version:||Operating system type:||Windows|
|Operating system version:||XP PRO SP2|
This goes back to v3.0, just verified in 3.1.5.
Create a symbolic link in Linux server as:
ln -s ~/path/dir linkname
FTP to server and refresh FZ and linkname appears in the tree.
Clicking on it returns error 550, No such file or directory,
may return Critical error,
sometimes reports "Failed to retrieve directory listing"
and then "Disconnected from server" -- even though it is still connected.
Manually disconnect and reconnect. No change.
Connect to a different server, disconnect, come back to the first server, then refresh, and the link is now recognized in v3.0. In 3.1.5 the link never seems to get recognized.
After this, I can't seem to find a pattern: I have a couple symbolic links that work and some that don't, all on the same server, with the same owner/group permissions, under the same user /home, etc. The ones that don't work were updated more recently but I don't see anything in permissions or anything else to explain them not showing up.
How can we clear the FZ cache entirely so that a CWD and "LIST -a" actually get the current server state? I'll provide debug data and any other diagnostic info if requested.
Change History (1)
comment:1 by , 15 years ago
|Status:||new → closed|
Restarting the client clears all caches.
The link resolving is done by the server. Assume you're initially in /foo before you do the ln command.
FileZilla then does the following:
CWD /foo (only it is not already in /foo)
In future attempts during the same session, it directly CWDs into the directory returned by the final PWD of the first change attempt.
Make sure to only use absolute symlinks, relative ones can cause problems with some servers. Also, check if your shell did expand ~, otherwise it is a relative symlink to ./~/path