GNOME Bugzilla – Bug 355851
File Dialog shows Backup Files
Last modified: 2009-06-12 10:10:16 UTC
Please describe the problem: For some reason, my file open dialog displays backup files created by Gedit, even when I have the preference in Nautilus *not* to display hidden files. This can be a major issue if you accidentally open the backup file instead of the current file. Steps to reproduce: 1. For instance, when I want to open "text_file.txt" I Ctrl+O. 2. What I actually see is this: text_file.txt text_file.txt~ 3. I sometimes accidentally open "text_file.txt~" and make changes. Actual results: If I accidentally open the backup file and make changes to it, then go back and open the live file, I wonder where my changes were! Expected results: Life on earth would cease. Does this happen every time? Yes. Other information:
This does indeed happen. The filechooser should probably have a way to specifiy whether or not to show backup files or backup files could simply be included in the hidden files support already available. The nautilus setting does not affect the filechooser in anyway since it is only a nautilus setting, not a system wide setting.
Since this would only affect GTK+ filechoosers and not, say, the output of ls in a directory, I think the onus of change is on Gedit. I've filed bug #438763 to this effect, suggesting that backup files be prepended with a dot to make them hidden more conventionally like they already are in Nautilus.
I'm sorry, but I disagree with you Andrew. In Nautilus, these files are only viewable when I choose "View Hidden Files". The file selector's behavior should be consistent with the Nautilus file browser, as they are very similar components. So it's either a problem with Gedit AND Nautilus, or it's just a problem with the file selector. Which is simpler to fix? Also, is there anyway to fix this manually, for now? I can barely see what file I'm trying to open up.
the definition of a "backup file" is application-dependent: some editors add a '~' to the end of the file name, some use an extension, some others use a dot-file, some others use a dot-file with an extension. gtk+ would have to filter every single "backup file", which will break as soon as some application defines its own backup format, and this is sub-optimal because you might very well open a file that's considered backup by some application with another application.
(In reply to comment #3) > So it's either a problem with Gedit AND Nautilus, or it's just a problem with > the file selector. Which is simpler to fix? You're forgetting ls and other command line utilities. This tilde~ behavior is GNOME-specific, so of course they'd be consistent. Nautilus is doing extra work here to make this work. What I'd hope for is something that would be more application-independent, preferably using the already-established convention of adding a dot to the beginning of the file. I wouldn't mind if GNOME wanted to do this tilde thing... in addition to adding a dot. :) Of course, I'm not a developer; I'm just expressing my opinion. > Also, is there anyway to fix this manually, for now? I can barely see what > file I'm trying to open up. I think the only way right now is to turn backup files off: /apps/gedit-2/preferences/editor/save/create_backup_copy: 'Whether gedit should create backup copies for the files it saves. You can set the backup file extension with the "Backup Copy Extension" option.'
(In reply to comment #5) > What I'd hope for is something that would be more application-independent, > preferably using the already-established convention of adding a dot to the > beginning of the file. I wouldn't mind if GNOME wanted to do this tilde > thing... in addition to adding a dot. :) using a dot-file doesn't cut it: what happens if the file you're editing already is a dot-file? vim, for instance, uses a dot and an extension (.swp) for its backup/history file. in any case, until there's a common reference implementation for backup files, the file chooser has no way to exclude one instead of another - unless we dump the code from nautilus inside it, leading to duplication and potential bugs.
(In reply to comment #6) > (In reply to comment #5) > > > What I'd hope for is something that would be more application-independent, > > preferably using the already-established convention of adding a dot to the > > beginning of the file. I wouldn't mind if GNOME wanted to do this tilde > > thing... in addition to adding a dot. :) > > using a dot-file doesn't cut it: what happens if the file you're editing > already is a dot-file? vim, for instance, uses a dot and an extension (.swp) > for its backup/history file. Since the goal is to hide backup files, wouldn't .file and .file~ work? The backup file would have a different name than the main file, but still be hidden. But in general, yes, I suppose a common implementation specifically for backup files would be ideal. :)
Attached is a patch that fixes this: backup files are considered as hidden files. It works in a very clean way since there are only a few places where I've had to add g_file_info_get_is_backup() next to g_file_info_get_is_hidden(), which are very similar calls. I've tested it and I did't find problems. I've listed all occurrences of "hidden" in GTK so I guess I've changed all the code that needed to be: the new behavior should be consistent everywhere with the patch. Though, in gtkfilechooserentry.c:391, the autocompletion code never shows files starting with a '.', and a comment says it would be good to disable this is hidden files are displayed. Backup files end with '~' and are named after an existing file, so autocompletion won't really bother about them because, so it's not a problem to my eyes, but I wanted to let you know. In gtksearchenginesimple.c:226, there's the same assumption, but I think it's quite remote from the filesystem browsing I'm trying to improve, so no conflict here. If you think it's worth making this two occurrences compliant with the new behavior, I can easily do it, but that would require creating GFiles in place where only paths are considered. So I guess they should be omitted. I've not added comments anywhere since the code is self-explanatory and that hidden files' detection is done in very few occurences. But I'm ready to improve this anywhere I think it would be good. Thanks for reviewing this, I hope we'll eventually get rid of all those harsh criticisms against the GtkFileChooser! ;-)
Created attachment 129590 [details] [review] Patch against HEAD that treats backup files as hidden files in GtkFileChooser
...and another patch to review here!
Lovely patch; simple and to the point. Milan, are you going to Gran Canaria Desktop Summit? I owe you a beer, at least :) I've committed this as a27e748586a007910aac394d891b40bb5325456e
Sorry, I'm not going! Though, I'm sure you can reward me by having a look at GtkFileChooser patches, for example bug 534462 needs some testing... ;-)