From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 Galeon/1.3.17 Description of problem: On my Dell C640 laptop with FC2, Nautilus has trouble displaying ftp directories which contain subdirectories with years as names. (2000, 2001...): in either spatial or browsing mode, icon/list views, those subdirectories do not appear correctly. In one case I get the equivalent of an ls -l as directory name; those can not be opened. If I create a directory with a year name in an otherwise empty directory (with gftp outside of nautilus for instance), nautilus doesn't display anything. If there is more than one it behaves as above. If I try to create such a directory within nautilus, the renaming creates an error. Version-Release number of selected component (if applicable): nautilus-2.6.0-4 How reproducible: Always Steps to Reproduce: 1. Start nautilus. 2. Access an ftp directory with write acces with `Connect to server...' 3. Using gftp or another ftp client, access the same directory and create a Test directory and a subdirectory called 2004. 4. Try displaying the Test directory with nautilus. Actual Results: The directory displays as empty. gftp confirms the folder 2004 exists. Expected Results: Nautilus should show the 2004 directory. Additional info: The immediate guess is that there is a parsing error in reading the FTP `ls' output. Here are a few examples of the `ls' output: drwxr-xr-x 2 frog-par ftp 192 Mar 11 2003 2002 drwxrwxr-x 2 frog-par ftp 144 Aug 17 10:01 2004 The file names as displayed by nautilus are exactly identical: drwxr-xr-x 2 frog-par ftp 192 Mar 11 2003 2002 drwxrwxr-x 2 frog-par ftp 144 Aug 17 10:01 2004
Created attachment 102973 [details] Screenshot of wrong display of subdirectories with year names This shows the icon view of a directory containing subdirectories with year names...
Looking quickly at the source code it seems it is a (known) bug in gnome-vfs rather than nautilus (cf. lines 216--221 in libgnomevfs/gnome-vfs-parse-ls.c from gnome-vfs-1.0.5-18). Since gftp must be doing the same parsing somewhere and gets it right, I tried to see if there was an obvious way of using gftp's implementation... but it's not obvious!
Created attachment 103000 [details] A possible (incomplete) patch The attached code is a possible solution. The idea is that since the name is at the end of the `ls' output, and since any non-year filename is well parsed, we append a char `a' at the end of the line before doing the parsing with gnome_vfs_parse_ls_lga in libgnomevfs/gnome-vfs-parse-ls.c, then we remove the last char from the parsed substring. I didn't test with nautilus, only with the small test program extracted from the source which is attached, so it is not a proper patch. Also I'm not very knowledgeable about how GTK programming really works so there may well be serious memory management errors for instance. To compile: $ gcc -g `pkg-config --cflags --libs glib` -o p parse-ls.c To run (for example): $ ./p "drwxr-xr-x 2 frog-par ftp 192 Mar 11 2003 2002" Parse = 2002
Created attachment 103015 [details] Better version of previous `patch'
Created attachment 103093 [details] A working patch for gnome-vfs2 The attached patch for gnome-vfs2-2.6.0-8 solves the problem with nautilus, for the server I access at least. I'm running it right now and will see if any problem arises.
Fedora Core 2 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC3 updates or in the FC4 test release, reopen and change the version to match.
I had the occasion to try on FC4 and the bug still exists and should be reopened; however I do not see on Bugzilla any efficient way of reopening a bug (is it a permission problem?) In any case the situation is the same as before. I haven't tried yet if the patch I was using still applies.
("ASSIGNED" is reopenned. Moving to FC4.)
gnome-vfs 2.14 should fix this.
Indeed, it's fixed even in FC5 (gnome-vfs2-2.14.2-1.i386.rpm); I had not checked after updating to FC5. Thanks!