GNOME Bugzilla – Bug 524880
filename with 43 or more chars are not shown
Last modified: 2008-05-07 15:14:13 UTC
this bug was reported at: https://bugs.launchpad.net/ubuntu/+bug/208524 "I uploaded file to my freebox hard drive (it is a french set top box) But the file didn't display in nautilus while it does well in gftp or another ftp client. With some tests i discovered that the file is not displayed if its name is longer than 42 characters. It is really easy to reproduce ... just open an ftp and rename a file in it to increase its length and the file will disappear from nautilus."
I was able to reproduce this only using the ftp backend, the sftp doesn't seems affected, a screenshot demonstrating this is attached to the launchpad report. - At the bottom left, a console with the first line containing 0-9 digits until complete 42 chars, and the following lines some files with names starting from 41, 42, 43 and 77 characters, without considering the file extension as part of the name, only the first 3 first files are displayed using gvfs ftp backend. - The bottom right console shows a ftp client listing the content of the directory containing the test files, displaying every file. - At the top, nautilus using the gvfs ftp backend listing just the 3 files which doesn't exceed the 43 chars barrier.
i meant to say "40, 41, 42, 43 and 77 characters" at the first point and "42 chars barrier" at the last point. sorry about those typos and possibly the others i don't detect yet
I was the one that reported it in launchpad. As a matter of fact it is a duplicate for launchpad bug #218010 which is associated with gnome bug #528346. Can you make this one a duplicate of the previous bug ? Thank you for your help Fabien
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of 528346 ***
*** Bug 528346 has been marked as a duplicate of this bug. ***
sorry for the mess, (From comment #1 in 528346) > This bug can be tested on this server : > > ftp://leservicetechnique.com/ > username : "username" > password : "nothing"
Why does bug 528346 is a duplicate of this one? Finally the real problem has been confirmed to be >6 spaces in file names and not >42 characters. I believe that we should set back this bug as a duplicate or at least import the title and description of the other bug report.
because this one was opened first and you should have commented there and updated the title rather than opened a duplicate
Thanks. Can someone import the title and description from bug 528346? The actual title and description of this bug is inaccurate. Sorry for the noise. Steps to reproduce: 1. Have a FTP server. 2. At the root of the FTP server, create a file called "d d d d d d d d.mp3" with some FTP client (Filezilla here). 3. Open the FTP server through nautilus. This bug can be tested on this server : ftp://leservicetechnique.com/ username : "username" password : "nothing"
The bug is due to ParseFTPList.c returning an incorrect result.fe_fnlen counting the trailing \r in some cases which makes ftp_filename_construct() no consider the filename as correct. Benjamin suggested removing the trailing \r in do_enumerate_directory() on IRC, the change works correctly so I commited to gnome-2-22 and trunk now * daemon/gvfsbackendftp.c: (do_enumerate_directory): remove trailing '\r', that workarounds a parser issue causing some filenames to not be listed (#524880)
*** Bug 523902 has been marked as a duplicate of this bug. ***