W3C home > Mailing lists > Public > public-device-apis@w3.org > January 2010

Re: New filesystem/directory API proposal

From: Arve Bersvendsen <arveb@opera.com>
Date: Fri, 29 Jan 2010 23:12:22 +0100
To: "Eric Uhrhane" <ericu@google.com>, public-device-apis@w3.org
Message-ID: <op.u7bemwjqbyn2jm@galactica>
On Fri, 29 Jan 2010 22:32:11 +0100, Eric Uhrhane <ericu@google.com> 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)
Arve Bersvendsen

Opera Software ASA, http://www.opera.com/
Received on Friday, 29 January 2010 22:13:03 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:41 UTC