> 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