Linux-kernel mailing list archive 2000-32,: Re: NTFS-like streams?

# Re: NTFS-like streams?

Andrew Pimlott (andrew@pimlott.ne.mediaone.net)
Fri, 11 Aug 2000 21:37:31 -0400

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Theodore Y. Ts'o: "Re: lock_kernel() & kmalloc - evil together?"
- Previous message: Johannes Erdfelt: "Re: Via Apollo Pro 133A"

On Fri, Aug 11, 2000 at 01:06:44PM -0600, Jeff V. Merkey wrote:
> i.e. The NTFS method is filename:attribute_name. This means folks just
> append :attr_name to the filename to tell the underlying FS to open an
> alernate attribute file. In this way, this method could be implemented
> across all the FS's in Linux. The question is whether utils check for
> the ':' character in the name stream. You need to expose this lower
> down since NTFS will store them as attributes, but other FS's could
> store them as alternate files, much the same as is done with HFS and
> Macintosh resource forks and finderinfo today in Linux.

I don't know enough to be confident about the best solution, but it
would be really nice if attributes could be directly accessible via
the filesystem. I say this mostly because I'm hooked on the
filesystem interface of Rational ClearCase. If I have a versioned
file foo.c in a directory, "ls" shows me foo.c, and "cat foo.c"
shows me some appropriate version of foo.c, but I can "cd foo.c@@"
to get into the version history. It's amazingly handy. And because
the directories are hidden to normal utilities, it is entirely
compatible.

I think you should consider something similar: either magic hidden
directories (foo.c:/attr) or magic dual-persona file/directories
(foo.c/attr). This is better than magic hidden files (foo.c:attr)
because you can "ls foo.c:" to see the attributes. I think anything
non-hidden is out of the question for compatibility reasons.

The biggest remaining problem is that if I "cp foo.c
somewhere_else/" in ClearCase, I expect to get only my appropriate
version of foo.c copied; whereas with an NTFS file, I probably
expect all attributes of the file to be copied. I presume NT copy
does something other than "while (read) write" to achieve this. The
only solution is to make Linux file utilities do something analogous
to what NT copy does. But this is orthogonal to the surreptitious
exporting of attributes via the filesystem.

Overall, while exporting attributes via the filesystem does solve
all problems, it improves ease-of-use enough to be worth it, even if
it requires a special utility to copy files with attributes. In
analogy to ClearCase, I still have to use ClearCase for many
operations (eg, checkout), but being able to run vi and grep on
arbitrary versions is a huge win.

Andrew

PS. I'm not a filesystem hacker, and Rational has not ported their
filesystem interface to Linux, so I have no idea how feasible this
is. But Rational's filesystem does work on several unices.

-
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.tux.org/lkml/

- Next message: Theodore Y. Ts'o: "Re: lock_kernel() & kmalloc - evil together?"
- Previous message: Johannes Erdfelt: "Re: Via Apollo Pro 133A"