Re: File API: File's name property

On Thu, Aug 29, 2013 at 9:48 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> As currently specified File's name property seems to be a code unit
> sequence. In zip archives the resource's path is a byte sequence. I
> don't really know what popular file systems do. Given that a File has
> to be transmitted over the wire now and then, including it's name
> property value, a code unit sequence seems like the wrong type. It
> would at least lead to information loss which I'm not sure is
> acceptable if we can prevent it (or at least make it more obvious that
> it is going on, by doing a transformation early on).
>

I don't think it makes sense to expect filenames to round-trip through
File.name, especially for filenames with a broken or unknown encoding.
File.name should be a best-effort at converting the platform filename to
something that can be displayed to users or encoded and put in a
Content-Disposition header, not an identifier for finding the file later.

We may also want to restrict "\" and "/" to leave room for using these
> objects in path-based contexts later.
>

Forward slash, but not backslash.  That's a platform-specific restriction.
If we go down the route of limiting filenames which don't work on one or
another system, the list of restrictions becomes very long.  If path
separators are exposed on the web, they should always be forward-slashes.

-- 
Glenn Maynard