This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The following changes should be added to the File API: 1. File.name represents a [EnsureUTF16] DOMString attribute for user agents to represent a file name as retrieved from the underlying file system; it may lead to data loss across client-server scenarios. It must not allow for "/" or "\" characters. It will be a parameter to the File constructor. 2. File.rawName should be an ArrayBuffer attribute representing the raw bytes of the filename. It is not a constructor attribute, and should represent the raw bytes of the File.name attribute. In this change, File.rawName will always be a byte sequence representation of File.name.
While an additional step can be to make sure File.name is [EnsureUTF16] I don't think File.rawName is necessary for now. But I'll leave this bug open in case it proves itself useful, especially for a non-ZIP archive use case. I'm not so sure putting it in to prevent theoretical information loss for a given filesystem is useful at this stage.
Yeah, basically need to know about http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0442.html For zip archives we could even consider requiring an encoding to be specified and just decode the paths using that encoding. And be gentle with failures. Not sure if that's general purpose enough though.
Fixed, but strictly along the lines of Comment 1. We're not doing File.rawName.