Advanced file systems? (was: [boost] [filesystem] size() on directory?)

From: Daryle Walker (darylew_at_[hidden])
Date: 2004-02-07 05:02:17

On 2/2/04 11:32 AM, "Beman Dawes" <bdawes_at_[hidden]> wrote:

> How should size( "foo" ) behave if "foo" is a directory?
> 
> 1) Throw. The function should be renamed file_size().
> 
> 2) Return 0. Directories don't strictly speaking have a size.
> 
> 3) Return the number of entries in the directory. Directories are really
> just containers; so of course they have a size.
> 
> (1) and (3) seem most attractive to me; (2) seems useless for directories,
> and probably misleading.
> 
> The problem with (3) is that for many (most?) operating systems the
> implementation would have to iterate over the directory to get a count, and
> this difference in complexity compared to getting the size of a file (which
> is usually constant complexity) could be pretty surprising.
> 
> I'm inclined to go with (1), naming the function "file_size", and then add
> a function later to get the number of entries in a directory. But only if
> there is enough demand. I don't want to clutter up the library with a lot
> of seldom used functions that can be trivially written as user code.

I guess that the file-system library is based around the Unix/POSIX model of
single-part files, purely-container directories, and a minimum of attributes
(creation/modification dates, permissions, etc.).  But there are file
systems beyond that.  Some of them support arbitrary attributes.  Some of
them support files with multiple parts, an extension of the "resource fork"
idea from pre-X Macs.  Most importantly, these features are also supported
for directories.  In this case, files and directories are identical, except
that files do _not_ have the ability to "contain" other files.

With this sort of file system, a "size" function for directories does make
sense.  Such a function would return the sum of the sizes of the file
object's forks.  If you go along with this, we should add APIs to access
properties per individual fork, and add a new corresponding I/O-stream.

IIUC, examples of these advanced file systems would be Apple's and
Microsoft's latest offerings.  I think Apple started it first, but has
totally disabled it except what's needed to support pre-X files.  Microsoft
doesn't need it at all, but has it fully enabled!  (I've read that this
decision has resulted in some security bloopers.  For example, someone could
look at an empty file in his/her text editor and wonder why it takes up so
much disk space, not knowing that the data was placed in a custom fork and
an old text editor can't recognize that.)

Does any Unix(-like) system support this idea, besides Mac OS X?  I've heard
that Linux was experimenting with this.  Obviously, any non-advanced file
system could be supported with any new APIs we make; just assume that the
file system supports only one fork (with an empty name?).

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT hotmail DOT com