On 2/2/04 11:32 AM, "Beman Dawes" <bdawes@acm.org> 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