[lkml]   [2000]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: NTFS-like streams?


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 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?
> >
> > % < 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
> > Please read the FAQ at
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to
> Please read the FAQ at

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:58    [W:0.155 / U:4.780 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site