Al,
One argument for this is the fact that lots of NT posix apps are going
to start to show up on Linux, and lots of folks who code on NT (me being
one of them) like to use this attribute scheme since it makes it easy
for folks to attach notes, info, etc. to files for data-mining apps and
the like. If we adopted the MS naming convention for this, it would
make porting a lot of these apps to Linux easier.
Jeff
"Jeff V. Merkey" wrote:
>
> Al,
>
> We need a VFS method call to alias NTFS style attributes (which are
> really just special files) for my NTFS file system driver for Linux (not
> the one based on the current NTFS driver). This could be implemented as
> an ioctl() to the file system itself for individual files, however,
> these types of attributes use a unique naming convention that could be
> easily trapped by the fileutils (ls, mv, etc.) and treated transparently
> as a file on any FS in linux.
>
> 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.
>
> In NTFS proper on NT, they are implemented as special files.
>
> The question is whether the linux fileutils and code paths will barf is
> they see an ':' in the filename. You could parse this in the VFS and
> indirect to an attribute file, but some FS's like NTFS would want to
> deal with the name string directly. If this something too alien to
> Linux, or dumb idea, and what do you think? Something like on HFS
> would do nicely.
>
> Please advise,
>
> :-)
>
> Jeff
>
> "Jeff V. Merkey" wrote:
> >
> > The way NTFS does this trick is to create special attributes and chain
> > them from the MFT for a given file entry. Linux has nothing like it at
> > present in it's standard file systems, and the linux NTFS driver is only
> > a bare skeleton of NTFS, it does not implemen all the NTFS
> > capabilities. Under the covers of NTFS, these attributes are actually
> > LCN (logical cluster number) file chains with some fancy headers and a
> > name.
> >
> > :-)
> >
> > Jeff
> >
> > Urban Widmark wrote:
> > >
> > > On Fri, 11 Aug 2000, Christopher Vickery wrote:
> > >
> > > >
> > > > I'm interested in implementing a system that associates
> > > > meta-data with inodes, and would like to know if it has
> > > > already been done or is in the works. NTFS allows you to
> > > > create multiple "streams" within a file. "echo hello > x:y"
> > > > creates a zero-byte file named x with a "stream" named y
> > > > containing hello. If you copy, move, rename, or delete x
> > > > then y goes with it. Canonical example is x.bmp contains an
> > > > image and x.bmp:thumbnail contains a thumbnail of the
> > >
> > > Erm. What is the point?
> > > If you read x.bmp do you eventually start reading x.bmp:thumbnail?
> > >
> > > % make_thumbnail.sh < x.bmp > x.bmp:thumbnail
> > >
> > > Now you have two files
> > > x.bmp
> > > x.bmp:thumbnail
> > > :)
> > >
> > > To create something you can copy, rename or delete with one operation, put
> > > it in a directory.
> > >
> > > > image. So far as I can tell, the NTFS for Linux project is
> > > > not under active development, and ext3, reiserfs, jfs, etc.
> > > > do not deal with this issue. Am I missing anything?
> > >
> > > Re ntfs; Anton Altaparmakov is doing "Odd Fixes" (see MAINTAINERS). If
> > > such files can be created on ntfs then it would perhaps be nice to be able
> > > to access them. I'm sure he will appreciate all help.
> > >
> > > Re others; it's not unixy ...
> > >
> > > If you look at such a file exported with SMB what does the client see?
> > > Can you do "echo hello > //server/share/x:y" ?
> > >
> > > /Urban
> > >
> > > -
> > > 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/
> >
> > -
> > 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/
-
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/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:25 EST