On Wed, 20 Jan 1999, Troy Benjegerdes wrote:
> Correct me if I'm wrong, but both AFS and coda keep data on the servers
> (in the RVM data file??) which allow one to recover files from 24 hours
> ago. My univerisity has AFS, and I have recoved files I accidentally
> deleted a couple of times like this. I also recall reading in one of the
> coda manuals that this is possible.
Unfortunately, (as Jan points out in another email, I think) what you are
actually seeing is the daily clone of your home volume. This usually
appears in AFS volumes in a directory called 'OldFiles'. A 'clone' volume
in AFS is a copy-on-write duplicate of the original volume, and must
reside on the same server. Essentially, it allows for an atomic snapshot
of a volume to be created; the meta-data is duplicated on the server, but
the directories point to the same files in the /vicepa partition with
refcounts. When a file is modified in the original, the clone forks its
own copy. Many institutions find this to be an efficient way to provide
hassle-free backups of recently modified data, as it uses little storage
(most files aren't changed, most of the time). However, because the
clones are atomically created at a discrete point, this is not the same as
it being a log of all past versions of the file.
As Jan points out, a 24 hour log would limit reintegration to a 24 hour
disconnect period, also. The logs on the servers, as I understand it, are
there to provide transactional support, and used during resolution of
conflicts; they do not constitute a complete (or even sufficient) history
to be used in reintegration.
> If this is the case, the reintegrating client could request the full
> version of the original file to allow reintegration.
The best solution that Jan and I could come up with from a few minutes
banter was to conclude that writes to a file should only be allowed when
the entire file has been retrieved by the client; as such, conflicts would
be prevented from occurring to partial files. We think that allowing
early access to the data during the sftp transfer from the server would be
quite feasible; we threw around a few proposals concerning how to do that
(especially dealing with seeks and large files), and what to do if a
process tries to read a partial file when disconnected.
Robert N Watson
[EMAIL PROTECTED] http://www.watson.org/~robert/
PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C
Carnegie Mellon University http://www.cmu.edu/
TIS Labs at Network Associates, Inc. http://www.tis.com/
SafePort Network Services http://www.safeport.com/
