Re: New filesystem/directory API proposal

On Wed, Feb 3, 2010 at 4:08 AM, Anselm R Garbe <garbeam@gmail.com> wrote:

> On 29 January 2010 22:12, Arve Bersvendsen <arveb@opera.com> wrote:
> > 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)
>
> 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
> that.
>

You'd then be putting the burden on the sites using the APIs and not the
UAs.  I think most of us can agree that's a bad thing.

Having a 1:1 correspondence between on disk file names and virtual file
names without resorting to a lookup table should be a requirement for our
solution, I think.  Having implementations escape characters that won't work
on their platform + a very small number of reserved characters (though isn't
strictly necessary) seems like the way to go.  Because there'll always be
some platform/file-system in the future with other weird rules/conventions.
 Which I believe is what Hixie is also advocating for.

J