Opened 13 years ago

#7954 new Bug report

Default Remote Directory sometimes fails if Default local directory is not found

Reported by: File Rick Owned by:
Priority: low Component: FileZilla Client
Keywords: default directory Cc:
Component version: Operating system type: Windows
Operating system version: Windows 7 Home Premium 64-bit

Description

When the local default directory was set to a directory on a non-existent, removable drive, the REMOTE default directory would fail with an error (in red) displaying "no such file or directory". This even failed with a copy and paste from the "Remote Site:" pulldown. No failure was noted for the local directory error. This also occurred in 3.3.4.1 so I immediately upgraded to 3.5.3 with the SAME results.

After modifying the local default to an existing directory, the remote default now works. Switching the local default back to the non-existent directory, to test this again, NOW the problem does NOT occur. (It appears that once the remote directory is accessed as a default, it appears to stay working.)

This occurred 12-15 times as I attempted to figure out what error I was making in the remote directory (It had to be something because there was an error each time. I slowly reduced the number iof subdirectory levels and finally attempted "/" which gave a failure as well. Each attempt was a "Connect" and "Abort" via the Site Manager.

I thought that I had done something wrong on the remote default, somehow, but when I PASTED the result and it still failed, I was perplexed. Yes, I checked for trailing spaces and even added a trailing "/" and removed it, yielding the SAME results. I thought it was a problem with symbolic references to a directory, but only after the LOCAL default directory was made to work did the remote directory work.

All I can say is that it failed several times, but now I know a workaround.

Therefore, I have lowered the priority of this bug, but created the ticket because it HAD happened. There is an easy workaround -- make sure the local directory works properly.

Even if nothing is changed, if someone else has the problem, they might find this workaround -- make sure the local directory exists.

Change History (0)

Note: See TracTickets for help on using tickets.