Re: System.Directory (was RE: Proposal for a new I/O library design)
pathSeparator :: Char '\\' on Windows, '/' on unices, ':' (I believe) on macs, etc...
Used to be ':' in Classic MacOS, and there are still some old routines in Apple's Carbon library that take ':'-separated paths. However, Apple always insisted that Pathnames should only be used for display purposes, mostly because a pathname did not always uniquely identify a file (!). Mac OS X uses "normal" unix-style paths for everything that concerns us. Also, the "Classic" Mac-style paths had different semantics (no "." or "..", etc.), so treating them would have been more difficult than just using a different separator. Fortunately, they're a thing of the past.
directorySeparator :: Char ';' on Windows, ':' on unices, i have no idea on macs
As there was no command line, no PATH, and no textual config files on classic Mac OS, there is no mac-specific directory separator, so it's ':'. (although I think that stealing yet another character from
isCaseSensitive :: Bool False on Windows, True on (all?) unices, i have no idea on macs
It's not that easy. Case sensitivity is a property of a file system, not of the operating system. So if you mount a Windows or Mac OS volume on a Linux system, the filenames on that volume will still be case-insensitive (but case-preserving). On Mac OS X, the default file system type is HFS+ (a.k.a. Mac OS Extended), which is case insensitive, but you can also choose UFS (case sensitive). You could also have both, on two partitions. Of course, "False" for Windows and MacOS, "True" for everything else is a reasonable guess, but you can't rely on it. Right now I have no idea how to implement something like isCaseSensitive :: FilePath -> IO Bool which would determine whether a specific path would be case sensitive. Maybe it's worth the effort to think about it.
given just these, i think we'd all be a lot happier.
I agree. If the last one can be implemented properly, that is. Cheers, Wolfgang
On Mon, Jul 28, 2003 at 07:51:51PM +0200, Wolfgang Thaller wrote:
isCaseSensitive :: Bool False on Windows, True on (all?) unices, i have no idea on macs
It's not that easy. Case sensitivity is a property of a file system, not of the operating system. So if you mount a Windows or Mac OS volume on a Linux system, the filenames on that volume will still be case-insensitive (but case-preserving). On Mac OS X, the default file system type is HFS+ (a.k.a. Mac OS Extended), which is case insensitive, but you can also choose UFS (case sensitive). You could also have both, on two partitions. Of course, "False" for Windows and MacOS, "True" for everything else is a reasonable guess, but you can't rely on it. Right now I have no idea how to implement something like
isCaseSensitive :: FilePath -> IO Bool
See 'statfs(2)' and 'fstatfs(2)', there should be enough info there to implement it. plus an interface to the other information returned by these functions would be useful. perhaps we need a standard trinary data type, True,False,Unknown. I guess (Maybe Bool) works. John -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john@foo.net ---------------------------------------------------------------------------
On Mon, 28 Jul 2003, Wolfgang Thaller wrote:
It's not that easy. Case sensitivity is a property of a file system, not of the operating system.
Actually, it's not even that easy. The NT native API allows you to specify case sensitivity as a flag when creating or opening a file in any directory (at least on NTFS). You can create file entries this way which are inaccessible from the Win32 subsystem because they're shadowed by other names in the same directory which differ only in case. If we ignore that complication, I think the right way to handle this is with dIsCaseSensitive :: Directory -> IO Bool. Assuming, as always, that there's a way to implement that. Or perhaps it should be Maybe Bool instead of Bool.
isCaseSensitive :: FilePath -> IO Bool
I don't think it's clear what this should mean. Assuming you have a case-insensitive filesystem rooted at /mnt, what should isCaseSensitive "/mnt" return? The filesystem rooted there is case-insensitive, but the pathname passed to the function is 100% case-sensitive. (This also has the usual problems associated with any function which uses pathnames. See my comments on the Libraries list.) -- Ben
participants (3)
-
Ben Rudiak-Gould -
John Meacham -
Wolfgang Thaller