Re: New filesystem/directory API proposal

On 29 January 2010 22:12, Arve Bersvendsen <> wrote:
> On Fri, 29 Jan 2010 22:32:11 +0100, Eric Uhrhane <> wrote:
>> No file or directory may be named any of [CON, PRN, AUX, NUL, COM1, COM2,
>> COM3,  COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5,
>> LPT6, LPT7, LPT8, LPT9], nor may a file or directory's name begin with any
>> of those strings followed by a period.
> Note: These are perfectly legal on many filesystems, but will specifically
> fail with Windows.
>> Filenames may not end in period or space.
> These are perfectly legal filenames on many systems.
>> Paths can't contain any character in the set [<>:"/\|?*] or whose
>> representation
>> in UTF-8 is in [0-31].
> This is the NTFS limitation, right?
> It's at this stage I would like to note that file system limitations, if
> they are to be made into a common subset of common Unix filesystems, HFS/OS
> X and FAT/NTFS (Windows), we are looking at a rather restrictive subset, and
> we would possibly be left in the situation where a web application will be
> unable to address files already present on the user's file system.
> While we might enforce these rules for creation of new file handles, we
> can't enforce them on reading
> Any text for file name system limitations should therefore be informational
> in a spec, not normative.  (In general, I do support discouraging creating
> non-portable filenames)

Speaking as an individual, I'd avoid to find a suitable cross-platform
solution for these file name limitations. Imho it should be up to the
API implementation on a specific platform to support/fail in such
corner cases. On a Windows platform you'd simply have
case-insensitiveness, on a Unix/Linux platform you'd have
case-sensitiveness and support for all UTF-8 characters. Simple as


Received on Wednesday, 3 February 2010 12:08:41 UTC