> I think that because of NFS caching thats only true when a1 and > a2 deal with the same file -- i could be wrong however. If i'm right then > your proposal suffers the same problem (another client might see all of > the changes you've made to the version file and think the index is in a > consistent state, but not realize that the file is a stale cached file.
I don't know better than that, so let's assume that no order is guaranteed between operations on different files. I can see that in this case my version-file logic would fail. How about the numbered-files approach - would it work under this assumption? Say a writer wrote a new version, and at just the end of that wrote the appropriate segments file. A reader doing Directory-list would see the segments file of recent version N but might not yet see all the required index files for version N. I now think this is already addressed in this thread by having the reader know exactly which files are required to exist, and having the writer always creating all files, possibly as empty files. Under this no-order assumption, it is also possible that a file exists but only part of it is available for the reader - to defend against this the reader should be able to verify that the segments file is complete, and that each of the other files is complete - using the file length or so, right? > I'm not saying your proposal is bad -- just that i don't think it will > solve all the problems you think it will solve. No problem, I already agreed with that. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]