Derek Atkins wrote:
> Unfortunately the owner and mode information is vital information
> about the files..  It's like asking "i just rm'ed this letter -- how
> can I recover paragraph #3?".  You should restore from backup.
> 
> -derek

I see. Well I'm using AFS for some time now and I'm quite satisfied with
it's features.

But in some places like this I find it's a bit too sensible. Wouldn't it
have been better to use some encapsulated form for the internal AFS
data. A single binary file or a real own filesystem implementation for AFS?

I mean the structure in /vicep looks quite complex and relies on
features of the underlying filesystem (i.e. the inodes). That the file
permissions and ownership are so vital for the integrity of the AFS data
isn't a very beautiful approach in my opinion.

It looks to me like encoding meta information in the primary key of a
database table or such things.

Especially as I never noticed that there are special file permissions at
all even after one year of quite intensive working with OpenAFS. On the
top level of the vicep partitions are only the volume files which have
no special looking permissions at all. Only if you enter the AFSIData
folder you encounter the README file warning from altering permissions.

Besides the criticism: What is the most secure way of moving a complete
OpenAFS server installation (in case of only one server running) from
one machine to another? I haven't worked with the internal backup
support of OpenAFS yet. But I don't see a clean and easy way of securely
moving the complete installation.

Greetings,

Matthias



Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to