Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[REBOL] Re: NTFS Stream Fun

From: robert:muench:robertmuench at: 6-Aug-2002 11:05

> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]] > On Behalf Of Bruno G. Albuquerque > Sent: Tuesday, August 06, 2002 5:10 AM > To: [rebol-list--rebol--com] > Subject: [REBOL] Re: NTFS Stream Fun > It is not directly related to Rebol, but I would like to > point out that BFS, the native filesystem under BeOS does support
metadata
> (attributes) and the number of them per file is unlimited.
Hi, yes the BFS is a nice thing. I liked it a lot. NTFS supports this too, even it's mostly unknown. Ever looked at the "Summary" tab of a file properties dialog? All the fields you see there is meta-data stored with the file. This data is stored in an internal known steam. However, IIRC you can have a lot of streams in a NTFS file. BTW: The stream feature is AFAIK available since NT 3.1 (1994). What you see in a directory listing is the so called "default" stream. This stream has the form of <filename>:$DATA Further NTFS streams are not normally visible - unless you know one is there (and unless you know its name), you are out of luck. If you copy a multi-stream file to a FAT volume, all the streams will disappear except the unnamed stream. In addition, applications that transfer files and are not stream-aware only transfer the main unnamed stream, for example email clients. This makes it useful for things like license keys etc. Of course you can have a look at the MFT of a NTFS partition but all these steps need a lot of knowledge about NTFS. And Microsoft uses streams mostly for Macintosh support. Whereas the Windows 2000 Content Indexing Server adds an alternate data stream named "?Q30lsldxJoudresxAssqpcawXc" to image files on NTFS volumes. This stream contains thumbnails of the images. An even less common application for NTFS streams is the creation of hard links (Posix-style file links). These get done by writing, to a special stream ID (WIN32_STREAM_ID/BACKUP_LINK), the full path of the new link to create. And streams can not only attach themselves to files, they can also attach themselves to directories. This is a not so nice feature as streams can't actually be deleted. The parent they're attached to must be deleted in order for the stream to be removed. If you attach a stream to the root directory of a drive, such as "C::MyStream", you can't delete this one at all. So be careful. Further streams, as they are essentially still files, can be executed and do not have their filenames display correctly in Windows NT/2K Task Manager, the utility commonly used to view running processes. For example, if the stream "c:\test.txt:mystream" was running, Task Manager would only show "test.txt". And while we are at it, try to find a web-site running some older IIS servers and type in http://www.victim.com/target.asp::$DATA You will see the source-code of the ASP file. The server won't execute the code. However, operating systems can access streams on an NTFS share, independent of their file system. For example, a Windows 95 operating system with a stream aware client might view a stream on a Windows NT 4.0 NTFS network share.
> In other words, it completelly smokes NTFS out. :)
NTFS is not that bad. I like some features of BFS as well but IMO the NTFS is really a nice thing. I don't remember the title of a book (if you know it let me know it too) that tells the story about the NT development. Very good read! Not very technical, instead it tells about the people and up & downs while developing NT. There is a section about the development efforts that went into NTFS etc. Robert