[lkml]   [2000]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: abstract file (support multi-part)
On Sun, 20 Aug 2000, Albert D. Cahalan wrote:
>James Sutherland writes:
>> NTFS's streams are not HFS resource forks, although they can be used to
>> emulate the latter if needed.
>NTFS's streams are exactly like HFS resource forks. Old HFS filesystems
>had an implementation limit of 2, but HFS+ (used by MacOS X) lets you
>have as many as you like.
>> Similarly, NTFS streams are NOT OS/2 HPFS EA's - NTFS supports
>> them as well, and they are not related in any way to streams.
>I could almost agree with that. Really, you just get a second
>stream namespace. One can emulate the other until you hit a
>filesystem with both.
>Don't forget that XFS, UDF, JFS, and NFSv4 have this type
>of feature too. (JFS was hacked to support OS/2)

The last time I looked at XFS, it did not. It has the ability to hold
extended attributes, but no streams, no resource forks. Each attribute had a
limited size entry (64 bit value + name, I think). It also had a maximum
number of entries (256 or 512).

It DID have a user definable set of attributes, and a system defined
list (the user could NOT modify that list). The user set included
ACL entries.

Unfortunately, none of the backup tools would save anything EXECEPT the
ACL entries. see xfs_dump/xfs_restore for details.

Jesse I Pollard, II

Any opinions expressed are solely my own.
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 12:37    [W:0.054 / U:5.688 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site