Messages in this thread | | | Date | Wed, 2 Sep 1998 13:13:07 +1200 | From | Chris Wedgwood <> | Subject | Re: Implementing Meta File information in Linux |
| |
On Tue, Sep 01, 1998 at 07:07:59PM -0400, Albert D. Cahalan wrote:
> Then we must forget about ACLs, privs, the immutable bit... > We should be using 14-character unix filenames too. No, make > that 8.3 case-insensitive filenames. We must be portable!
All of the above gives us something and cost very little (ACLs are a little more complex here I suspect, I don't know them well enough to comment).
The immutable bit is useful - and it doesn't necessarily affect cp, rm, tar or any other commonly available program. Sure, if rm tries to nuke a file, it may fail in ways unexplainable by rm, but then that is the whole point of the immutable bit!
(Off-topic: Actually, another use for the immutable bit would be that executables with this set could have RX only (not W) pages in the code segment, as *BSD currently does).
Longer filenames have done no significant harm - and most other unicies allow them in similar ways. All the gnu tools I'm aware of handle them adequately.
> I think not. New features have to start somewhere, and they spread > to other filesystems as time passes. We already need a forked file > API for ntfs, hfs, and smbfs.
Yes - and HFS and netatalk are already using one, and it works.
> All our current tools (NFS, tar, cp, mv etc) fail already. They > don't handle all the ext2 flags. They certainly don't handle Coda > or FAT. What else is new? Userspace was, is, and will be broken.
Bullshit.
For the most part, NFS, tar, cp, mv do work. Yes, they don't handle certain ext2fs flags - and arguably neither should they. If I mark a file as immutable, it means I don't want it unlinked, and I don't care how fucken smart rm ever becomes, I don't want is unlinking files marked immutable.
> Windows has a FileCopyEx call that could be stolen. It deals with > all the extra data, including both security attributes and strange > forks. It can avoid network traffic when the server supports the > call.
This can be done in userspace.
> 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 - there are legitimate needs for metadata, and for metadata to be truly useful, most existing applications will need to be updated to take advantage of this, and if this is the case, then why make the solution a kernel-space one when a user-space library may do just as well.
If you really think userspace isn't the way to go, then lets hear why and see what ideas people come up with to address them before adding (IMO) unnecessary features to the kernel that Linus probably won't accept anyhow (anyone got Linus' opinion on this anyhow).
A userspace solution could also work with other OSs - which is a huge win when trying to get any kind of interface or API off the ground.
-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
| |