(Illustration by Gaich Muramatsu)
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 robert@fledge.watson.org 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/Received on 1999-01-20 18:14:15