[OpenAFS] Restoring ownership information of filesystem structure on /vicep*

[Christof Hanke]

Hi,

Matthias.Gerstner@student.fh-nuernberg.de wrote:
> 
>>Russ Allbery <rra@stanford.edu> 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
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info