Re: Implementing Meta File information in Linux

Chris Wedgwood (chris@cybernet.co.nz)
Wed, 2 Sep 1998 16:36:07 +1200


On Tue, Sep 01, 1998 at 11:59:44PM -0400, Albert D. Cahalan wrote:

> > The whole point of ext2fs attributes is that thing like tar, cp, etc.
> > don't know about them!
>
> That is crazy. The same could be said of standard attributes.

No. Standard attributes serve a different purpose, security for
example, and is defined by Unix98.

ext2fs attributes are outside this scope and serve a different
purpose.

> You set the immutable bit because you want more work?

No. I set it because I don't want certain files clobbered by tar and
friends.

Doing this has effectively saved many ours of work, because various
applications have not been able to trash certain important files.

> I'd say you are paid by the hour.

I'm self employed. If I were to be paid by the hour, it wouldn't work
out to be very much.

However, this isn't relevant.

> If tar fails to mark files immutable, your restored filesystem is
> corrupt. If tar can clobber an immutable file, I'd say it is your
> own damn fault for giving tar permission to do so.

tar != `file-system backup utilitity'

Yes, under many circumstances it can be used as such, and is indeed
very useful, but I don't think tar was designed for backing up
filesystems (files maybe).

> It is dumb because there is no way for it to support the features.
> If there were system calls to handle the job, cp would use them.

No, it wouldn't. cp's job isn't to do all sort of high-level cruft
IMO.

What you want is really_smart_cp_not_unix_like_cp, not cp.

> Compatibility is good. Without it, it is hard to replace every
> other OS with Linux.

True, but its not going to happen. Choices are good, and there will
always be choices.

We can't assume like some people do, that we are correct and that our
way is the one try holy way and eventually all other will fail.

> >> You'd have the server uncompress and recompress all the data too.
> >
> > Compressions != forks. Its an entirely different matter.
>
> The system calls needed for fork support overlap with those
> needed for efficient compressed file support. In this case,
> both would be greatly helped by a file copy system call.

How so - please explain. Examples might help.

> ACLs exist. Forked files exist. Unusual file attributes exist. How
> do you propose to backup and restore everything? Don't forget to
> cover all 3 time stamps without interrupting atime updates during
> the backup. Filesystem-specific answers are generally bad.

All the features you talk about are file-system specific, so I don't
see why solutions can't be filesystem specific.

Assuming inodes are allowed to change, all of the above is possible
using a directory as a container for forks.

-cw

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html