(Illustration by Gaich Muramatsu)
On Fri, Oct 11, 2002 at 08:49:39AM -0400, Matthew R Welland wrote: > > 1. Make the inconsistent file listable but neither readable or writeable > (this file could possibly be the version as it was on the server before the > conflict. > I believe this already happens, the file in conflict gets converted to a symbolic link to the coda object id (I think it is the obj id) > 2. For each possible version of the file create a new file in the same > directory with a naming scheme such as > <originalname>.host_where_modified.uniquenumber where the > host_where_modified portion can help the end user choose which copy > to keep Hmmmm, without being rude, it sounds like you never actually worked through a repair session. This is pretty much what happens when you start a repair of a conflict, the coda file system is "split" into the local version and the server version (for a local/global conflict). By viewing both versions you can use the repair tool to decide whether to preserve of discard the local modifications (or you could copy off one version of the file if a manual merge needs to be done). Once you have processed the modification list and decided what modifications stay and which ones go then you commit the changes, end the repair and then the two "views" disappear leaving a single coda tree again. > > 3. Allow CODA to keep running! Having the filesystem become unavailable due > to some lock file being inconsistent is not fun. I am sure Jan can explain better than I, I just have this vague feeling that keeping the filesystem running in the face of conflicts could get really messy really quickly. > Use some standard > mechanism to notify the end user that there is a problem. I think someone was working on a sort of monitoring tool that would let you know when there was a problem. > What does nfs use > when a server goes down? > Oh, the ever so subtle hint of any process touching the NFS mounted FS stopping dead in it's tracks until the server comes back ;-) If you are lucky the fs will be mounted interruptable so you can at least kill the hung process, if you are trying to write then you are pretty much dead in the water until the server returns (well, there are soft mounts but they are not recommended for writable volumes because of the risk of losing data) > I found the CODA repair process to be very difficult to comprehend and it > didn't (at the time) work very reliability. The suggested process would be > understandable to almost anyone in my opinion. > I have had some repairs fail on me but others have worked ok. The actual repair process is not simple and it does take a bit of practice to get the hang of, I am not sure how it could be made simpler - maybe it just needs to be documented a bit better to better explain what is happening. -- Brett LymnReceived on 2002-10-11 10:00:42