> If you're using my desktop machine for instance, I reserve the right as > the owner of the machine to change it out from under you at my whim. On a > timeshare system, of course you'd set it or unset it and be done.
:-) sure. > > In ro volume -#foo-> in ro volume foo (if available, otherwise rw) > > In rw volume -#foo-> in rw volume foo > > In ba volume -#foo-> in ba volume foo (if available, otherwise rw) > > only the last one should ever change. Yes, only the last one is the one that changes. > > In ro volume -%foo-> in rw volume foo > > In rw volume -%foo-> in rw volume foo > > In ba volume -%foo-> in rw volume foo > > these stay the same. Yes. > > The folks that want to "get back" to the rw side of the universe > > can allways use rw (%) mountpoints, which in backup volumes have > > the same behaviour as type preserving (#) mountpoints. > > you mean currently, yes? Currently, yes. nneul> oh damn, I just screwed something up, quick - remount the .backup nneul> volume so I have some time to fix it. And then you want to traverse back into the "new" three for mountpoints "further down". I see. I have never done it that way, I have allways mounted the backup volume somewhere else and then copied content back. When deleting and makeing a new mountpoint like you do, I would not be sure what happens with processes with a CWD there? > The real issue is semantics for a .backup tree, I think. Yes. I think that #foo = stay in volume type if possible and cross over to rw if not %foo = cross over to rw is good. Is there any need for ?foo (for some "?") to cross over to other volume types if available or is mounting #foo.backup and #foo.readonly good enough? Harald. _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
