GNU bug report logs - #12507
24.2.50; `bookmark-write-file': use `write-file', not `write-region', to get backups

Previous Next

Full log

Message #52 received at 12507 <at> debbugs.gnu.org (full text, mbox):

From: Karl Fogel <kfogel <at> red-bean.com>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 'Chong Yidong' <cyd <at> gnu.org>, 12507 <at> debbugs.gnu.org
Subject: Re: bug#12507: [debbugs-tracker] Processed: severity 12507 wishlist
Date: Thu, 27 Sep 2012 10:48:22 -0500

"Drew Adams" <drew.adams <at> oracle.com> writes:
>>
>>   * As Drew suggested, change `bookmark-write-file' to use 
>>     `write-file' instead of `write-region'.
>> 
>>   * Also change the default value of `bookmark-version-control' to be
>>     `nil' instead of `nospecial', so that backups of the bookmark data
>>     file are no longer on by default (unless there are already backup
>>     files present).
>
>But how does that help a user turn backup on in the first place?  Not a
>rhetorical question - I really don't know.  How should a user create the first
>backup file?
>
>What would the doc suggest to the user for that?  Copy the file to one with a
>`~' suffix (error prone)?  Visit the bookmark file, type SPC then DEL, then `C-x
>C-s' (error prone)?
>
>What is an easy, sure way for a user who has never backed up a file
>(one that is not typically visited interactively) to create a backup?

Set `bookmark-version-control' to `t', of course.

Best,
-K

>The question is not bookmark-specific.  I don't know a good answer.  It's
>probably obvious, but I'm not seeing it.
>
>> But... the only thing that makes me hesitate is the first 
>> step, because back in 2005 we changed `bookmark-write-file' to use
>> `write-region':
>> 
>>   2005-11-12  Karl Fogel  <kfogel <at> red-bean.com>
>>         * bookmark.el (bookmark-write-file): Don't visit the 
>>         destination file, just write the data to it using
>>         write-region.  This is similar to revision 1.32 of
>>         saveplace.el, but with an additional change to avoid
>>         visiting the file in the first place.
>> 
>> The corresponding change in saveplace.el has just this comment:
>> 
>>   ;; Don't use write-file; we don't want this buffer to visit it.
>> 
>> Why didn't we want to visit the file?  Was there some reason why that
>> was a bad thing?  Unfortunately, I don't remember, but I don't want to
>> introduce a regression.
>> 
>> Drew or anyone, any idea what problem we were avoiding?
>
>Sorry, I don't know.  I bisected the change logs from the start, to locate that
>commit as the culprit change.  But I don't know more than what the log says.
>
>Perhaps the reason was what Yidong expressed: a belief that a bookmark file is
>only an "internal configuration file", rather than user data (presumably because
>users do not typically edit it directly).  His contention is that backing up the
>file would annoy users by littering their filesystems.
>
>If that was the rationale for the 2005 change then it was misguided, IMO.
>
>A bookmark file is not just an internal config file.  It contains user data that
>can be valuable (to users).  Among other things, it can contain metadata (e.g.
>annotations) about other files.  It has some things in common with Org mode for
>keeping track of positions and other relations among documents.
>
>Users can make mistakes that lead to losing individual bookmarks that they might
>really want to keep, or even to losing all bookmarks.
>
>In the other direction, it is very easy to load a second bookmark file into your
>main bookmark file and save the result without necessarily meaning to.  To get
>back what you had (by deleting the additions or replacing the replacements) is
>laborious and error prone, unless you have a backup copy.
>
>For such reasons, some users might want to have automatic backup for their
>bookmarks.  I agree that backup should be optional and up to the user, of
>course.
>> The status quo does seem a bug.  There are two fixes: make 
>> backups work again, or deprecate `bookmark-version-control'
>> and don't claim that the bookmark data file can have automatic backups.
>> 
>> (In the meantime, Drew's suggestion in #12503 that `print-circle' be
>> bound to `t' seems right to me -- I'm trying to get outstanding
>> bookmark.el bugs fixed in time for the feature freeze on Oct. 
>> 1 and that should be one of the fixes.  If so, then one of the reasons
>> for being able to back up the bookmarks data file will go away anyway.)
>
>Thank you for that, in advance.
>
>There are however plenty of other ways a user can lose a bookmark file that took
>a long time to construct.  To me, we should not only provide automatic backup
>but turn it on by default.
>
>(Would I apply the same arguments to some other "internal config files"?
>Dunno/depends.  Maybe desktop files.  A lot depends on how important the given
>"config" might be to a user and how long it takes to reconstruct it from
>scratch.  In any case, I don't buy the blanket argument that dot files or
>"internal config files" are necessarily things that a user does not want backed
>up.)
>
>---
>
>I would in any case like to know an answer to my question above about creating
>the first backup.
>
>I also have a question about the idiom to use that would make a code change
>analogous to the write-region --> write-file change discussed, but for
>(write-region (point-min) (point-max 'APPEND), i.e., for appending the buffer
>content to a file.
>
>It's not clear to me what the best way would be to replace that code with code
>that will not only append and write but also back up (if backing up is enabled).
>I can code something up by appending the text to a buffer and then calling
>`save-buffer' etc., but I wonder if there isn't some standard, simple way to get
>this effect.
>
>Thx - Drew

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.