Jeffrey Altman <jalt...@secure-endpoints.com> writes: > For the afs administrator it is perfectly reasonable to assume a "vos" > command interface which should not be tied to a cache manager. The afs > administrator is comfortable working with the concept of volumes. It is > therefore not unreasonable to require the administrator to refer to > volume ids and paths relative to the volume root directory.
Hm. I think you may have a higher expectation of what AFS administrators are likely to understand than I do. I think they will be able to figure out paths relative to the root directory, but I think it's extremely unintuitive for the path to be relative to the volume root directory and not the current location. I'm not sure there's much point in implementing relative paths to the volume root if we can't implement arbitrary paths. I would lean towards just requiring fs getfid untli we can implement arbitrary paths. At the least, we should reserve the more intuitive -dir option for arbitrary paths and use a different option for paths relative to the volume root. > For an end user, I would believe that an "fs" command would be more > appropriate. The fs command can rely on a cache manager to take more > general paths in the name space and resolve them into the necessary > volume and relative path. I cannot imagine ever allowing an end user to split volumes at Stanford. We draw a hard management line at volume creation. If we were to provide this functionality to end users, we would do so via a remctl interface to a system with AFS administrator privileges that would impose our naming standards. For example, we require registration of all volumes in a database as part of the creation, which is handled by the wrappers that we use. I'm not sure that's really a useful path to explore. It feels to me like a significant change in the AFS authorization model, given that it means VLDB changes which I believe currently can only be done by people in UserList. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info