Custom Query (7979 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (52 - 54 of 7979)

Ticket Resolution Summary Owner Reporter
#2146 who's the owner/group of a file? anonymous
Description

I'd like to know who is the owner of a file when I

change its permissions. And the group would de nice too. Bye.

#7804 fixed whitespace in filename cause download failure Chun-Hao Wu
Description

I happen to have a file named ' 01.xxx.mp3' (xxx was Taiwanese). The whitespace prefixing the file name causes downloading errors. The filezilla server log shows the process.

(000005)2011/10/29 下午 23:56:44 - user (211.76.77.44)> 227 Entering Passive Mode (140,113,205,141,8,75) (000005)2011/10/29 下午 23:56:44 - user (211.76.77.44)> RETR 01.xxx.mp3 (000005)2011/10/29 下午 23:56:44 - user (211.76.77.44)> 550 File not found

Yes, the filezilla client correctly requested the filename as 'RETR 01.xxx.mp3', which has two whitespaces after RETR. It's just the server cannot find it.

The issue can be worked around by deleting the prefixing whitespace. It's weird that when I tried to rename ' 01.xxx.mp3' to '01.xxx.mp3', windows 7 told me a file with that name already exists. I copied that file to the same directory, getting both '01.xxx.mp3' and ' 01.xxx.mp3'. Then, I deleted ' 01.xxx.mp3' and this time I can download '01.xxx.mp3' as usual.

So I'm unsure if this issue belongs to filezilla server or windows 7 or the FTP protocol.

Perhaps the problem is that all whitespaces between RETR and the filename are ignored by filezilla server?

#8249 outdated when downloading a directory tree, a random part of it may not be downloaded matteo sisti sette
Description

I right-clicked on a directory (that contained a lot of subdirectories with thousands of files) on the server and selected "download".

During the download process I lost connection a few times and sometimes had to restart filezilla (because of another bug, that sometimes you can't resume processing a queue until you restart filezilla), but then I always resumed; that shouldn't be a problem at all. I never, ever deleted anything from the queue nor did I ever receive any error prompt to which I could have given the wrong answer.

After hours of downloading, the queue was finally empty and FileZilla was apparently done downloading. Then I found out that more than half of the directory tree simply HADN'T BEEN DOWNLOADED.

I don't know whether the missing directories have never got into the queue (I'm ALMOST sure this was the case) or if they did and then they failed to download, but in both cases SILENTLY failing to download is a disaster.

If a queue becomes empty and you haven't explicitely deleted anything from it, you must be 100% sure that everything in it has been downloaded. And if you download a folder, you must have 100% guarantee that all its contents get added to the queue.

I SUSPECT that the queue is built (i.e. the directory tree scanned) while the download is ongoing, so in case of huge directories, if the download is interrupted and resumed, maybe the scanning of the directory is not resumed properly. If that is the case, than that is the bug. Either the whole scanning of directories and queuing of files should be done prior to starting to download, OR actions should be taken to ensure that in case of interruptions the scanning is resumed reliably.

Assuming that downloading a directory tree is always done without the slightest network error or without restarting FileZilla from the beginning to the end in one chunk, is a ridiculous assumption.

Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.