lkml.org 
[lkml]   [1998]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Implementing Meta File information in Linux
On Tue, Sep 01, 1998 at 10:41:26PM -0400, Albert D. Cahalan wrote:

> Long filenames (over 14 characters) broke stuff everywhere.

True. But code expecting 14 or fewer character filenames is/was
broken anyhow. Also, way back then, linux was a mere shadow of its
current self and far less useful for many thing I presently use it
for. Breaking it back then would piss of a few hackers, breaking
stuff now will piss of millions of clueless (because, like it or not,
linux now has a large enough install base to almost be considered
main-stream).

Oh, and at the time many other OSs never had the 14 character
restriction.

> What about tar though? If you must restore from a backup, wouldn't
> you want to keep the immutable bits? How would you copy a directory
> tree with ext2 attributes intact?

The whole point of ext2fs attributes is that thing like tar, cp, etc.
don't know about them!

If I want to backup (or more to the point restore) files where the
immutable bit has been sent, then some manual intervention is going
to required which is precisely why I set the immutable bit in the
first place!

Thats not to say dedicated backup programs shouldn't know about the
immutable bit, because in this case it could be smarted than tar and
utilize other precautions, but I'd be positively slutted if I did a
'tar zvx' and it clobbered a file I'd marked immutable for some
special reason.

The point is, I know what my intentions are for certain files, tar
doesn't and never will. I can enforce my policy using the immutable
bit, and thats very useful.

> Now, you want to haul several gigabytes of data over 10baseT
> and lose all the information that Linux can't understand???

Not at all... but it desn't make it a kernel space solution and
either way, cp is a `dumb' program that doesn't know about all these
features.

I'm leaving ACLs aside, because that _has_ to be done is userspace
and there does exist (in part) a frame-work and design for doing this
under linux anyhow.

The linux-kernel doesn't need, nor should it have, every immaginable
feature or misfeature that another OS has got.

In the example you sited, linux doesn't know about NT permissions and
making is smart to these evenusing ext2fs ACLs will require
condsiderable additional information on group mappings, RID mappings,
etc.

As for data forks - what wrong with the way hfs does things?

> You'd have the server uncompress and recompress all the data too.

Compressions != forks. Its an entirely different matter.

> That looks like a 30-minute operation, plus data loss
> which causes a security hole. No, that is not OK.
>
> Perhaps Bob should bypass the kernel filesystem. He could do raw
> network I/O to reach the server using a setuid /bin/cp.
>
> >> Windows has a backup API that handles all the details. Microsoft
> >> could add weird new features to the filesystem without breaking
> >> backup tools. The backup API requires special privilege and lets
> >> the backup admin avoid disturbing _any_ of the time stamps.
> >
> > This can be done in userspace.
>
> Sure: unmount the filesystem and hit the raw device. That kind of
> downtime is simply not acceptable for many business uses.

wtf are you talking about?

We can define a usable API for accessing user-space

-
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

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.823 / U:0.876 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site