Re: autosave/restore software fails

[Tim Mooney <mooney@aps.anl.gov>]

re...,

Tim Mooney wrote:

> ... Corruption is
> expected and is handled well in every scenario I've seen. 

I almost forgot.  There are two situations that have come up in
the past in which autosave doesn't (and maybe can't) do the right
thing:

1) If autosave has write permission to the .sav files, but does not
have write permission to the directory that contains them, the files
can be written, but their lengths cannot be changed. If the save set
contains string-valued PV's, and those strings get longer, the file
will effectively be truncated -- silently, as far as I've been able
to determine.  Autosave will detect this, and it will decline to
overwrite the other (good) .sav file, but it will nevertheless be
failing to save new PV values.  The obvious thing to do would be to
start a new file, but without write permission to the directory, it
can't do this either.  I think the most practical solution in this
case is to just to make sure autosave has write permission to both
the files and the directory.

2) If the directory that contains the .sav files is renamed while
autosave is running, it will not work correctly.  There are several
ways in which the failure can happen, some worse than others, but
none really good.  At best, the files are written through the old
file handle, and on the next reboot, restore doesn't find them.

Tim Mooney