Bug 79698 - Disabling backups (file~) explicite, disabling backups for version-controlled files, custom backups dir
Summary: Disabling backups (file~) explicite, disabling backups for version-controlle...
Status: RESOLVED WORKSFORME
Alias: None
Product: kate
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR wishlist
Target Milestone: ---
Assignee: KWrite Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-04-15 15:28 UTC by Marcin Kasperski
Modified: 2012-10-25 18:58 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcin Kasperski 2004-04-15 15:28:01 UTC
Version:            (using KDE KDE 3.2.1)
Installed from:    Compiled From Sources

A few things related to the kate behaviour of saving backup files (file.c~) for the edited files:

a) It would be nice if one could disable backup-making feature in configuration so backups are not generated at all.

b) It would be nice if, even when backups are generally made, they were NOT generated for version controlled files (CVS, RCS, maybe Subversion). Such a behaviour would be nice (if I version control the file, I can always revert to the version from the repository and file~ is not needed). Maybe worth noting: *emacs behaves so.

c) Finally, it would be nice if I could change placement of those backups, using some special directory for them (say instead of saving /home/me/some/directory/some/file.txt~ kate would save /home/me/.backups-dir/some/directory/some/file.txt~). Maybe this backup dir could be implemented as a general KDE utility similar to trash-can with some corresponding GUI.
Motivation: ~-files pollute work directories and are rather seldom used...
Comment 1 Jason Keirstead 2005-01-11 16:14:43 UTC
I vote for option (c) +++++

At first, I thought I could set the backup prefix to /var/backups to accomplish this, but alas, this does not work.
Comment 2 Jeroen Wijnhout 2005-01-11 16:18:55 UTC
It is not a good idea to disable these backups. When Kate saves the file it creates a backup, then it empties the file and starts writing. Suppose you don't have a backup and Kate crashes when saving your file. Result: your work is gone!

You can put *~ files in .cvsignore.

best,
Jeroen
Comment 3 Anders Lund 2005-01-11 16:55:15 UTC
It is possible to disable them, but as jeroen stated, not advisable. It's a *very* common behavior, about any editor uses is (emacs, vim, joe, jed, nano, u name it).
Comment 4 Jason Keirstead 2005-01-11 17:02:04 UTC
I don't want to disable them.

I want to say " put them in ~/backups/<full path>"

Having all that clutter in the current directory is, as the poster said, very messy, especially when the directory is version-controlled. It is also messy when you are often making tar.gz backups of the directory, so you are basically backing up the backups.



Comment 5 Marcin Kasperski 2005-01-11 17:04:17 UTC
Emacs does not save backup files when it detects that the file is version controlled :-)

Nevertheless, we all probably agree that from 3 option given variant c) (ability to specify special backup directory instead of backuping in place) is the best one.

Placing ~ in .cvsignore does not work because CVS is not the only tool one uses. konqueror, rgrep, ... (add as many tools as you like here) all show/access those backups. Even if there is a way to omit them, each tool require different one.
Comment 6 Thiago Macieira 2005-01-11 18:46:50 UTC
> Emacs does not save backup files when it detects that the file is version
> controlled :-)

Yes, it does. I only use Emacs to edit KDE code. Look at this:

$ ls -1 ~/programs/src/kde/kdelibs/kdecore/*~ | wc -l
34
Comment 7 Marcin Kasperski 2005-01-11 19:42:31 UTC
Either you changed the option managing this feature (I don't remember emacs case, in xemacs it is 'Make Backup Files' option in 'Version Control' config group), or those ~ files are made BEFORE the files started being version controlled (the scenario: you create a.c, then you save it so a.c~ is created, then you add a.c to version control - but a.c~ is already there so it stays).

Comment 8 Thiago Macieira 2005-01-11 20:38:00 UTC
Neither one nor the other. The files are backup files of CVS-controlled files because Emacs renames them with the revision that was edited:

$ ls -1  kmail/*~
kmail/kmmainwidget.cpp.~1.144.~
kmail/kmmainwidget.h.~1.40.~

And I have not configured almost anything in my Emacs. My ~/.emacs is very, very simple. It could be a distribution-default, though.
Comment 9 Philippe Rigault 2005-01-12 04:43:07 UTC
> Nevertheless, we all probably agree that from 3 option given variant c)
> (ability to specify special backup directory instead of backuping in place)
> is the best one. 

I certainly don't, option c is _very_bad_ for several reasons:
 1. Applications that make backup files (which includes all editors) _always_ make them in place. It is a _standard_ that all users would expect. Consistency of interface being one of the strengths of KDE, it would be a pity to ruin it by inconsistency of such a basic behaviour.
 2. It is not feasible easily in a robust way, and quickly brings many more problems than benefits. Consider the following scenarios:
  a) Backup directory problematic (not enough space, read-only NFS-mount), which is detected at _write_ time, so you do all your editing and the editor bombs just as you hit Save.
  b) ~/backups/<full path> is very inefficent. Edit a single file in kdepim for example, and end up creating $HOME/.backups/opt/build/kde/3.3.2/konstruct/kde/kdepim/work/kdepim-3.3.2/kmail/file. 
  c) Modify a file path (PATH1/foo -> PATH2/foo) after its backup is created guarantees that files do not correspind any more to their backups.
  d) ~/backups/<full path> fails to work across many machines. Often, home directories are shared betwen machines (e.g NFS mount). Go edit a file in machine1:path/file and machine2:path/file -> name collision.

The only reasonable option IMO would be to add the option in 'preferences' for cleaning up the backup file (after each save, when closing a file or exiting the application) and the option to ask for confirmation to do so each time.

One can ask an application to clean up after itself, but certainly not to mess with directory structures.

Comment 10 Anders Lund 2005-01-12 11:12:09 UTC
On Wednesday 12 January 2005 04:43, Philippe Rigault wrote:
> The only reasonable option IMO would be to add the option in 'preferences'
> for cleaning up the backup file (after each save, when closing a file or
> exiting the application) and the option to ask for confirmation to do so
> each time.

That is what came to my mind too -- *allways* make the backups, and make the 
options 'remove backups'. I'm not completely sure about remote files in that 
case, do we need to create backups for potentially slow remote files?

-anders
Comment 11 Jason Keirstead 2005-01-12 13:39:01 UTC
I really dont underatand your arguments.

On January 11, 2005 11:43 pm, Philippe Rigault wrote:
>  certainly don't, option c is _very_bad_ for several reasons:
>  1. Applications that make backup files (which includes all editors)
> _always_ make them in place. It is a _standard_ that all users would
> expect. 

?? The backup would still be performed in-place. It would just not be in the 
current directory. The *location* of the in-place backup file is the main 
issue. 

> 2. It is not feasible easily in a robust way, and quickly brings many more
> problems than benefits. Consider the following scenarios: a) Backup
> directory problematic (not enough space, read-only NFS-mount), which is
> detected at _write_ time, so you do all your editing and the editor bombs
> just as you hit Save. b) ~/backups/<full path> is very inefficent. Edit a
> single file in kdepim for example, and end up creating
> $HOME/.backups/opt/build/kde/3.3.2/konstruct/kde/kdepim/work/kdepim-3.3.2/k
>mail/file. c) Modify a file path (PATH1/foo -> PATH2/foo) after its backup
> is created guarantees that files do not correspind any more to their
> backups. d) ~/backups/<full path> fails to work across many machines.
> Often, home directories are shared betwen machines (e.g NFS mount). Go edit
> a file in machine1:path/file and machine2:path/file -> name collision.

All these arguments have no weight.  There is no reason you can assume that 
the current working directory is not problematic for the same reasons - it 
could be low on space, an NFS mount, etc.

Aside from that, no one is suggeiting ~/backups or whatever be the default 
location. The suggestion is that there be an *option* for the user to put 
these files in a location other than the current working directory, where 
they are clutter. If I as the user, want kate to put my backups on ~/backups, 
that should be my perrogative. It is up to me to pick a good location, and if 
the drive is on a slow NFS drive / out of space / whatever, that is my issue.


Comment 12 Nicolas Girard 2005-04-07 14:53:35 UTC
To me, a backup directory would *definitely* be preferrable to the current situation, IMHO.

Also, there would be no need for a complete hierarchy in that backup dir, it would be far enough to putt all backup files in a flat way right into it. If a file of the same name already exists, overwrite it. It should be that simple (I mean, there should be an option for backups to be that simple).
Comment 13 Marcin Kasperski 2005-04-07 15:47:43 UTC
One more comment: in my opinion there is absolutely no need to mix two things discussed above:
a) temporary backup file made by editor while saving
b) persistent backup file left for the user in case he would like to revert to the pre-save file version

For instance I have read in the comment 2 that "When Kate saves the file it creates a backup, then it empties the file and starts writing. Suppose you don't have a backup and Kate crashes when saving your file."
It seems to me that it would be far better idea to save this way:
- create temporary file
- write to this file
- when the write is succesfully done, swap it with the main file (rename original to tempname, rename temp to correct name, remove previous original)
- in case of errors purge the temporary
There is small chance of error happening just while renaming the files, but the chances are very small, this is very simple operation. If you are paranoid, you can copy old orignal to the 'official' backup location, whatever it is

Nevertheless, whatever temporary backup is needed by editor while saving, there is no need to make it visible for the user.

Regarding 'persistent backup' - backup left for the user in case he or she woudl like to revert - I think, that in fact it is currently just unnecessary. We usually save often and we usually have unlimited or at least deep undo stack. In case of logical mistake, instead of looking to ~-file, it is easier and more natural to just undo until the expected version is met. As some people could get used to using ~-files, there can be option to use them but it seems absolutely unnecessary to pollute everybodys working space with never-being-used-files.
Comment 14 Nicolas Girard 2005-04-07 16:13:17 UTC
Marcin,

do you mean that ~-files were used in the process of what you just called 'temporary backup', up to now ? 
Comment 15 Marcin Kasperski 2005-04-07 16:46:36 UTC
I do not know. But I suspect that it could be so after reading some comments above (like comment 2).
Comment 16 Anders Lund 2005-04-07 17:21:51 UTC
Thursday 07 April 2005 15:47 skrev Marcin Kasperski:
> a) temporary backup file made by editor while saving


Shouldn't this be implemented on KPart level?

-anders
Comment 17 Jason Keirstead 2007-05-01 13:30:46 UTC
Just a comment...

The second poster said that having an option to disable backups is a bad idea simply because "When Kate saves the file it creates a backup, then it empties the file and starts writing. Suppose you don't have a backup and Kate crashes when saving your file. Result: your work is gone!"

Correct me if I am wrong, but this seems like THE WRONG way to save files. Every app I have ever worked on, the app saves the file to some NEW FILE on the filesystem (random chars.tmp) and then when the save is complete, renames the orignal file to somethinkg.tmp, renames the saved file to the name of the original file, then deletes the something.tmp. 

This way, during no stage of the file save operation is there a chance of you losing your original data, since file renames are atomic operations. No need for this "backup file" nonsense. Why doesn't Kate behave this way?

I always thought the point of these backup files was in case you saved an edit and decided to roll it back - which is way I always agreed with at least having an option to disable them for RCS/CVS/SNV controlled files.

I have realy not seen a valid argument for disabling these files. It is not "standard behaviour" by the way - the standard behavior for vim is to DELETE the working copy of the file when it is exited normally. The working copies only remain if the app crashes. In all normal cases of exiting the backups are removed by default, you have to change options to make them stick around.

So mainly I want to agree with comment #13 - kate should not use this method for saving files at all. And even if it does need a working copy that copy should be deleted by default on normal exit. It should only remain in the case of application crash.



Comment 18 Heiko Gerdau 2007-05-30 13:04:01 UTC
*** This bug has been confirmed by popular vote. ***
Comment 19 Steve V 2011-03-02 00:26:05 UTC
As a total noob I would like to be able to increase the number of backups, maybe to as many as five.
Comment 20 Vincent Petry 2012-02-20 18:09:29 UTC
Having the option to disable the creation of those *~ backup files would be enough for me.
Comment 21 Christoph Cullmann 2012-10-25 18:58:56 UTC
They are now off per default, we have vim like swap files to keep care of data on crashs.