GNOME Bugzilla – Bug 706131
Double g_object_unref() plus bad code flow for the INVALID FILENAME case when creating new file
Last modified: 2013-08-16 17:21:05 UTC
Hi, there's a double g_object_unref() plus a bad located IF (which should be independent but it's nested) in the code that handles an invalid filename when creating a new file, i.e. on nautilus-file-operations.c:create_job() . If you look at the code for copying a file in copy_move_file(), you can see a similar code for handling the invalid filename case but this time without the extra g_object_unref plus the IF it's independent so if it cannot correct the filename then it will show the standard error dialog. While in the create_job() case, no error dialog is shown the following critical is printed on the console: (nautilus:16177): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed Steps to reproduce: 1) Open a new file in Gedit and paste the following text that consists of two lines (take care to preserve the newline after "show up when" as that is the FAT illegal char that we need to trigger the bug): Folders that are bookmarked that are in mounted drives do not show up when drive is mounted like it used to in 12.04. The only way to access them is 2) In nautilus, open a directory which is in a FAT filesystem, for example by inserting a FAT formatted usb pen drive. 3) In Gedit, select the text you copied earlier, and drag and drop it into the nautilus fat folder. This will trigger nautilus to create a new file with the same name as the text dragged. What happens: The file is not copied, but no error dialog is shown, and in the console you can see the following critical: GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed What should happen: The file should be copied, with the illegal FAT chars replaced[1], or if the chars couldn't be replaced, show an error dialog stating the file could not be copied. Also no gobject-critical should be printed on console. [1] As is the case for other illegal chars, e.g. if you copy a file that has a : char in the filename, nautilus will replace it with a _ when pasting it into a FAT folder.
Created attachment 251840 [details] [review] Fix for bug
Thanks for the patch! I pushed this to master together with another couple of fixes, as the original patch wasn't enough to fix the bug completely in the use case you described. Closing as FIXED.
(In reply to comment #2) > Thanks for the patch! I pushed this to master together with another couple of > fixes, as the original patch wasn't enough to fix the bug completely in the use > case you described. Thank you!, yes I also saw that pango_log_attr warning but wasn't investigating it yet as I thought was not related to the other bug. > Closing as FIXED. By the way, shouldn't we add the \n char to the list of fat chars to replace? that was the specific char that triggered the bug for me, and it seems it's really forbidden in FAT, as shown here: Copy the file with \n in it from my home folder to the Videos folder, all in ext4 -> GOOD nelson@cartagena:~$ cp 'Folders that are bookmarked that are in mounted drives do not show up when drive is mounted like it used to in 12.04.txt' Videos nelson@cartagena:~$ Now copy the file to my usb fat drive -> BAD nelson@cartagena:~$ cp 'Folders that are bookmarked that are in mounted drives do not show up when drive is mounted like it used to in 12.04.txt' /run/media/nelson/MULTIBOOT cp: cannot create regular file ‘/run/media/nelson/MULTIBOOT/Folders that are bookmarked that are in mounted drives do not show up when\ndrive is mounted like it used to in 12.04.txt’: Invalid argument nelson@cartagena:~$
(In reply to comment #3) > By the way, shouldn't we add the \n char to the list of fat chars to replace? > that was the specific char that triggered the bug for me, and it seems it's > really forbidden in FAT, as shown here: Yeah, that should have been fixed by https://git.gnome.org/browse/nautilus/commit/?id=8ff0bf18f9db9ec328b6c0c460ca2d9c462ddbdd Basically all control characters < 32 seem to be invalid in FAT, so I changed the code to replace all of those as well.
(In reply to comment #4) > Basically all control characters < 32 seem to be invalid in FAT, so I changed > the code to replace all of those as well. Ahh didn't get that, perfect!