- 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
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