Opened 11 years ago
#7954 new Bug report
Default Remote Directory sometimes fails if Default local directory is not found
|Reported by:||File Rick||Owned by:|
|Component version:||Operating system type:||Windows|
|Operating system version:||Windows 7 Home Premium 64-bit|
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 126.96.36.199 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.