Messages in this thread | | | Date | Wed, 2 Sep 1998 15:07:36 +1200 | From | Chris Wedgwood <> | Subject | Re: 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
| |