Custom Query (7791 matches)

v3.16.1 gives an update for 3.17.0.1, even with the "check for update"-setting disabled. I am often abroad on a mobile pay-per-byte connection, and both dialog and mobile data costs pretty annoying.

I am aware of the general rule to install the latest version and try again before reporting the bug, which would ofcourse ' ' ' solve ' ' ' the problem as in not showing that there's a newer version.

My config (relevant sections):

<Setting name="Update Check">0</Setting> <Setting name="Update Check Interval">7</Setting> <Setting name="Last automatic update check">2016-05-16 23:01:59</Setting> <Setting name="Update Check New Version">nightly 2016-05-09 ​http://filezilla-project.org/nightlies/2016-05-09/x86_64-w64-mingw32/FileZilla_3_setup.exe 7088584 sha512 4c0b208c0d37cf4c0e24bea9dde489c0a6485692b2bf13b770769b4d7c7213d05af9110319d6f9ab73cdbd105bb95d3eb3fe60e69bd01307077d8c7bb98d23f4

release 3.17.0.1 ​http://downloads.sourceforge.net/filezilla/FileZilla_3.17.0.1_win64-setup.exe 6513888 sha512 4d5e5d426af9dd689cb8c070d528c849719dc18544de194475bf3a0f5e35f8c9d449749fb2074a68292579b267ee2b23d1e2b31bae20d7185aa44061cca6981c

3.17.0.1 (2016-05-09) ... I removed 'whatsnew' items for bug report brevity ... </Setting>

<Setting name="Update Check Check Beta">0</Setting>

When attempting to upload using FileZilla the server access does not list the directories. Unable to list directories is the error. At first I thought it was my problem then discovered after the update from my older version (3.9.0.5) is when the problem began. I rolled back to the 3.9.0.5 version and the app began to work correctly. I now ignore the prompt to update each time it loads. I have other clients that use FileZilla and I recommend to them not to update until further notice about this problem being solved.

Removing a folder fails if it was not created by a FileZilla Client and matches the following cases:

• this folder has a file ".DS_store" (Mac) in it (cannot remove file as well)
  
• this folder has a comma (,) in its name (in my case, it was created by a php script, I cannot open or rename the folder as well)
  
• this folder/file has some backslashes (\) in its name (also created by php; however, I was able to rename the folder and afterwards I could remove it)
  

For all cases, it fails "No such file or directory". I reproduced this bug (especially the first case) several times.

However, I can delete the folders by a webbased system having the same user/group-rights as FileZilla had.

Perhaps there are some more problems if the folder/file name is not binary and was created by some other ftp client? I think the problem could be the charcater code?