Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#28 backup file by copy instead of rename

closed
nobody
None
5
2005-10-24
2005-10-10
jras
No

The normal behaviour now is to create a temp file to
save the new data, then rename (move) original filename
to same name + .bak, then rename (move) temp file to
original filename. This process has the undesired
effect of change the names if editing a symbolic link file.
It would be nice to have the option (in preferences) to
change this process to first copy original filename to
same name + .bak and then overwrite the original
filename with the new data saved. This way it would
work also editing symbolic links to files.

Discussion

  • Zoltán Kóta
    Zoltán Kóta
    2005-10-18

    Logged In: YES
    user_id=149336

    Not so long ago there was a similar feature request (see
    #968845).
    We started to implement a new saving method, but after
    discussions (also with the reporter of the request) we
    dropped this idea. Using direct save of the database
    increases the risk of data loss.
    Would you really need this feature?
    (You can check patch 8, 9, and 11 at
    http://arch.pybliographer.org/index.cgi/kota@szbk.u-szeged.hu--pyblio/pyblio--extra--1.2).

     
  • jras
    jras
    2005-10-18

    Logged In: YES
    user_id=1359540

    The feature request #968845 was to remove backup, that could
    lead to data loss, but what i proposed here is to change the
    method of backup.
    As far as i can understand from patches you pointed, patch 8
    is to just drop backup (not what i want); but patch 9 seems
    to be just my request (change method of backup to copy as an
    option selectable by the user). I don't understand clearly
    the changes in patch 11. I could try to use patch 9 to
    modify my version by hand (my current version is 1.2.6.2-1
    from Debian).
    I cannot see why copying instead of moving the backup file,
    can increase the risk of data loss. I could rephrase it more
    detailed (with a explicit new step 2):
    1. Copy the original data to a new file named like original
    +.bak
    2. Wait to end of copy and check there where no errors
    reported in the copy process.
    3. Overwrite the original filename with the new data.
    The only problem i can see with this method is speed in
    copies of large databases in each save. In any case, this
    behaviour could be optional (preferences) so the user could
    decide which one method of save to use...
    Thank you for your interest and nice work.

     
  • Zoltán Kóta
    Zoltán Kóta
    2005-10-18

    Logged In: YES
    user_id=149336

    You are right. patch-9 contains something like what you want.
    (patch-11 just restores the original version, with adding an
    option for turning backup off.)

     
  • Zoltán Kóta
    Zoltán Kóta
    2005-10-24

    Logged In: YES
    user_id=149336

    Fixed in arch. See patch-220.

     
  • Zoltán Kóta
    Zoltán Kóta
    2005-10-24

    • status: open --> closed
     
  • jras
    jras
    2005-10-24

    Logged In: YES
    user_id=1359540

    I suppose you meant patch-26.
    I have used it to change manually my version (1.2.6.2-1 from
    Debian) until the patch reaches main version and the stable
    version is changed in Debian.
    It works OK and fullfills what I wanted.
    Thank you very much.