Hi,
[EMAIL PROTECTED] wrote:
Russ Allbery <[EMAIL PROTECTED]> writes:
Actually, no, it does NOT use anything special from the "inode" per se.
It DOES use the Owner, Group and Mode bits (which are standard Unix
metadata). It also uses the size (to know how big the file is). Why
aren't you complaining about that, too?
Much of the information is encoded in the directory structure/filename
as well.. But... Some information is encoded in the owner/group/mode.
First of all: There was no offense intended. I like AFS. But it surely isn't
perfect in every aspect as nearly no software is.
I don't work with the internals of AFS so I'm not competent to give any
reliable statements about it.
But AFS obviously relies on the features of the underlying filesystem as some
filesystems like ReiserFS don't work for it.
This is only true for the client-cache (/usr/vice/cache), but not for
the file-server partition(/vicep??).
And I'm pretty sure the file permission and ownership information was not
intended to provide information for a higher level file structure but just to
control access to files.
If you take a look into the file structure you'll feel at a glance that it doesn't seem good or right to have permissions and ownership assigned in a meaningless way. Meaningless in respect to the UNIX file system.
It works for AFS for many years now that's for sure. But I think a change of
this approach could ease the use of AFS and perhaps add more flexibility in
some places. Anyway it's an interesting topic in my opinion.
The namei-interface is as flexible as it can get. Using only POSIX- or
whatever metadata on a filesystem guarantees that you can use all of
them, including reiserfs. This might seem ugly to you, but is quite
protable (which usually means ugly if you have enough OS's to port to ;)
I guess you're a bit confused about client-cache, Namei-server and
inode-server. There's lots of information about these three cases on
this list.
Christof
I don't think you'll get any disagreement. Disliking it and fixing it are
unfortunately two different propositions.
*shrugs* I don't think it's THAT bad a solution as-is. If you look at
the namei fs code the layout is explained in a comment. It DOES make
a lot of sense why its done the way it is; metadata about an inode is
stored in the inode metadata, but file "name" information (FID/TAG) is
stored in the inode "name".. Makes sense to me.
I guess if it wouldn't make sense it wouldn't work at all. There are endless
approaches to software design that make sense. I think the question should be
if its a good solution in comparison to others.
gnu tar with the following extra options should do what you want:
-S -p --atime-preserve --numeric-owner
Yes I thought so. Usually I use the same procedure but in this case I had to
use scp and as a result I somehow forgot the preserve option.
I just thought there is a more elegant solution for it. But it's okay for me.
Greetings,
Matthias
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
