#1385 "update" refuses to overwrite backup file

None
closed-wont-fix
nobody
2016-09-04
2014-04-22
No

The "update" command refuses to overwrite an existing ".old" backup of the parameter file:


# just copy&paste to reproduce
set print "test1"
print "a=1"
set print

update "test1" # "test1" is copied to "test1.old" and afterwards updated
update "test1" # throws following error:

The backup file test1.old already exists and will not be overwritten.
 error during fit

This is in both latest windows testing binaries (465 and 50alpha, the later without the "error during fit"), but i think the problem is somewhat older.
Also gp465 still (see https://sourceforge.net/p/gnuplot/bugs/1156/?limit=10&page=1#92ed ) throws misleading error messages around "update", reported file names are incorrect and the "error during fit" thing shown above is nonsense.

Discussion

  • Karl Ratzsch

    Karl Ratzsch - 2014-05-28

    From looking at the code this definitely seems to be intended behaviour.
    I´ve just submitted a patch that updates the docs to reflect this.

    Still the errormessages in gp46 should get fixed.

     
  • Bastian Märkisch

    Doc update in CVS for version 5. Also, if the parameter file does not exist, 4.6 now emits a proper error messages.

     
  • Bastian Märkisch

    • labels: --> fit, update
    • status: open --> pending-wont-fix
     
  • Ethan Merritt

    Ethan Merritt - 2014-09-10

    Here's a thought.

    Would it not be cleaner all around if in version 5 the command is changed to

      update {oldfile} $DATABLOCK
    

    That way it will always succeed (existing old files are not relevant).

    This also avoids cluttering the current directory with new files (see e.g. tracker item https://sourceforge.net/p/gnuplot/patches/427/).

    If you do want to write the updated values either into a new file or on top of the old file, you can use the sequence

      update $DATABLOCK
      set print "somewhere/param.dat";  print $DATABLOCK
    

    Logically there should be a corresponding change so that "fit" itself accepts

      fit ...  via $DATABLOCK
    
     
  • Karl Ratzsch

    Karl Ratzsch - 2014-09-10

    I like the idea, but is there a need to break backward compatibility over that? "update" could just work on both files oder datablocks, the later being the "recommended" way.

    Of course that won´t resolve the original problem, then.
    But i say update should be changed to just overwrite the backup parameter file. If someone really cares about his old values, he has to save them someplace safe anyway. No use throwing an error over that.

     
  • Ethan Merritt

    Ethan Merritt - 2014-09-12

    CVS for 4.6 is currently broken because the existfile() mechanism knows nothing about gnuplot load paths. So if the parameter file is coming from $GNUPLOT_LIB or from "set loadpath", existfile() will not find it.

    This makes fit.dem fail and makes the update command test the wrong file before deciding whether to overwrite it or not.

    I am reverting the existfile() check for 4.6.6 so that "update" will act as it did in 4.6.5.

    We can continue to discuss how things should work in version 5.

     
  • Ethan Merritt

    Ethan Merritt - 2014-09-12

    Dang. The more I look at this, the messier it gets. So far as I can see your original report is not true for linux. The "param.dat.old" file is happily overwritten on each "update" command. So the change to the documentation is actually not correct for linux.

    So on linux the 2nd use of "existfile" is also incorrect. If the code ever reaches that test, something else went wrong. Directory ACL? Disk error? I can't seem to trigger it even if I try. Even if the file is entirely write protected it still gets replaced with a new file and the existfile() test is never reached. (All testing using 4.6 cvs).

     
  • Ethan Merritt

    Ethan Merritt - 2014-12-29

    Not fixed in 5.0
    I'll add this as a known issue in the Release Notes.

     
  • Ethan Merritt

    Ethan Merritt - 2016-09-04
    • status: pending-wont-fix --> closed-wont-fix
    • Group: -->
    • Priority: 5 -->
     

Log in to post a comment.