GNOME Bugzilla – Bug 108868
Want to specify backup directory
Last modified: 2010-02-07 09:46:30 UTC
gedit offers me the option of making a backup when I save a file. I want to be able to specify the direcotry where those backups are written; I do not want them in the directory where I'm working. I want a special backup directory in my home where all such files are kept.
This is a new feature request. Setting keyword to GNOMEVER2.3 and changing to enhancement.
Me too. Actually, I think this would be a candidate for a GNOME desktop preference / infrastructure. But as long as there is no such thing, I'd really like this a setting, because GEdit is currently distributing its backup files all over the place; and they aren't even visible in Nautilus by default. For example, the joe editor has it.
Created attachment 79354 [details] [review] Patch to implement this feature Adds a couple options to the Preferences dialog, and uses a gconf key to specify the directory for backup copies to be placed. If this key is empty--""--then it uses the current dir for backups (current behaviour). Inside that directory, backups are created in a hierarchal directory structure mimicking that of the original file's path to avoid name clashes. e.g: /home/henry/file with backup directory set to /home/henry/gedit_backups creates the backup: /home/henry/gedit_backups/home/henry/file~ I've tested it somewhat thoroughly. Also, I believe it doesn't create any memory leaks :) One thing I was thinking about was having another gconf key to say whether to use current directory or specified directory, although all this would gain us is keeping the old value of the specified directory in the preferences dialog if we've switched to using the current directory.
Created attachment 79425 [details] [review] Updated patch - fixes a couple of leaks g_free'ing the strings returned from gedit_prefs_manager_get_backup_copy_directory
For the moment I'd split the patch in two parts: - the prefs dialog - the core part Let us focus on the core part now. I'm not sure about the fact you create a hierarchal directory structure inside the backup dir. Can you see what other editors do in this case? As you said we should probably have two gconf keys. You should check the "mkdir" return value to manage errors. Note that gedit have two different strategies for saving backup files, do you take care of this fact? (pbor can say more on this).
I have not looked at the patch yet, but glancing at it from the bottom up I spotted + saver->priv->backup_dir = backup_dir; + } + g_free (backup_dir); This is wrong: the saver->priv->backup_dir pointer is left dangling and when you later use it it points to garbage (freed memory). You should freesaver->priv->backup_dir in the finalize method of the object.
>For the moment I'd split the patch in two parts: >- the prefs dialog >- the core part > >Let us focus on the core part now. Cool. Will upload soon. >I'm not sure about the fact you create a hierarchal directory structure inside >the backup dir. Can you see what other editors do in this case? vim with the backupdir option set, simply overwrites the backup. emacs doesn't seem to have any in-built method of specifying a backup dir for all backups; this script: http://www.northbound-train.com/emacs-hosted/backup-dir.el allows this functionality and optionally prepends a mangled ('/' -> '!') path to the filename and placing it in the backup dir. Personally, I think the hierarchal directory structure is the better solution, provided it doesn't have any problems with the two backup strategies; in which case, we can prepend a mangled path to the file name (I'm thinking path separators to '-' chars in that case?) >As you said we should probably have two gconf keys. Done. >You should check the "mkdir" return value to manage errors. Done. I don't think this was strictly necessary, however, as if it fails, the backup file won't be able to be created, and gedit pops up a message ("backup file could not be created") anyway. >Note that gedit have two different strategies for saving backup files, do you >take care of this fact? (pbor can say more on this). Need to look into this more to be 100% sure, but I don't think there is any problem here -- all I've changed is that it's returning a different filename for the backup than it was. Comments? Also, what are the best permissions to use in the mkdir_with_parents call?
Created attachment 79606 [details] [review] Patch for the core part (schema, prefs-manager, document-saver) Fixes the dangling pointer mentioned by pbor too
Created attachment 79607 [details] [review] Patch for the dialog part
Created attachment 79614 [details] Screenshot of the propsed preferences dialog changes
Created attachment 79716 [details] [review] Updated patch - core Implemented pbor's ideas (from IRC) There is now sanity checking in prefs manager on the dir (must be absolute, exist, and be a dir), and now defaults to home if anything is wrong. Also, filechooser button changes in sensitivity (appropriately) when the diff radio buttons are selected.
Created attachment 79717 [details] [review] Updated patch - dialog
Created attachment 79737 [details] New screenshot - showing new strings + filechooser insensitivity
Created attachment 79739 [details] [review] my version of the core patch Here is my version of the core patch: - the sanity checking I was talking about on irc goes in the file saver, so that if something goes wrong we can display an error message to the user. Beside we should not assert that the dir already exist: creating it at the first save is ok. - I modified it so that the default is ~/.gnome2/gedit/backups - I changed so that you can specify a absolute path, a path relative to home or if you use a path starting with ./ it is considered a path relative to the document dir, like vim does. This last feature is not exposed in the UI for now. - I removed the use of a hiererachy dir, since paolo had some doubts about it. For now it just uses basename (like vim) though enanching it to use a mangled path is easy, or even reintroducing the hierarchy: I think this is something we can do after the freeze. - If saving in the dir fails, we display a message the user telling to check is backup dir prefs and offering to save anyway. Bubbling up a more specific message is complicated, but I think that for now this is good enough. - When a saving dir is specified, we always use the fallback saving strategy, since we cannot be sure that the backup dir is on the same filesystem. As discussed on irc with paolo, this could be improved by doing try&handle error, however vim always uses the slow strategy too, so I think we can do this enhancement as a second step - The UI part of henrym seems ok, except I prefer s/file/document To sum it up I would real like to get this in today before feature freeze, since I think it si good enough: any objections?
Couple small comments: In gedit-prefs-manager.h, the default should be "~/.gnome2/gedit/backups"; currently the '~/' is missing. On that note, file_chooser_set_uri expects an absolute path (which is why I had the sanity checking in g-p-m); and so when the editor page in the prefs dialog is setup, if it's not an absolute path, the filechooser defaults to "Filesystem" (ugly). Which sadly, will happen on first use if the default key value is as above. Last one (really tiny) in gedit-prefs-manager.c; the get, set, and can_set methods for backup_dir pref can be replaced with the DEFINE_STRING_PREF... macro. Other than that it looks good. These things are fairly small and can be fixed after the freeze (I'm happy to help), so we should get it in beforehand :)
> In gedit-prefs-manager.h, the default should be "~/.gnome2/gedit/backups"; > currently the '~/' is missing. No, since the pref can hold both absolute and relative paths, a relative path should be interpreted as relative to ~. The dialog code should handle that. > Last one (really tiny) in gedit-prefs-manager.c; the get, set, and can_set > methods for backup_dir pref can be replaced with the DEFINE_STRING_PREF... > macro. You are right, I jsut edited on top of your patch
Created attachment 79748 [details] [review] patch Patch including the dialog and the above mentioned improvements. Note that I dropped the part that sets the default position of the file chooser button since it doesn't work: when setting the URI the file chooser pops up a dialog if the dir doesn't exist and we definately want to avoid this (since in most of the cases the dir will not exists the first time a user open the prefs).
mmm... actually now that I think of it there is a corner case that needs to be adressed: if the backup dir is the same as the document dir or a symlink to it (but we are not using 'save_in_doc_dir') we have a problem since both the original and the backup will have the same filename... which is the correct way to check this (strcmp doesn't work for the symlink case)
Is there any simple way of expanding all symlinks, to get the real path from it? Then compare and if it's the same as doc_dir, add backup_ext?
henrym: not sure... after all I think I'll hold back this feature from 2.17.3... it saddens me a bit since it really comes close to make into feature freeze, but it's 23:59 here, I have headache and I need to get the release done in an hour :( More importantely file saving is just to delicate to rush things and this RFE already waited 3 years: let's take the time it takes to get it right.
Fair enough, can't say that I'm not disappointed, however. I will probably help get this fixed properly over the next couple months, with the plan to get it in near the start of the 2.20 cycle then. :)
Well, disctcheck got stuck... so if you want to give a last try tonight ;)
Hi there... I'm so excited that you guys are so close to finishing this feature. Here's to you getting it into CVS soon.
This bug is quite old. Should it be closed and a new one opened against gedit 2.27 (2.28)? I'm looking for some input here. Is there any work being done on this, or did it just die out? I've written a plugin in python that does backup files to a folder of your choosing, and i would be glad to send it for review if anyone thinks this could be included in the official gedit package. It could in theory even replace the built in backup settings, if i include the option to also save backups in current directory, like gedit does today. It feels a little bit wierd to have this (built in, and plugin backup) setting in two locations though... The best solution would still be if the "classic backup" feature of gedit could do this, IMO.
I am closing this bug report: this days we have completely switched to gio and creation of the backup is not under our control anymore. Beside I think proper backup should be tackled at other levels: file system (I think zfs and btrfs do that), version control (git etc) and system backup tools. Finally as the last comment shows, for those really attached to this feature it can be done with a plugin. Sorry for those who put effort in the patch, but feedback in the last 7 yeard made clear that this feature is not so critical.