23160 2013-09-04 20:17:13 +0000 Add a File.rawName attribute on File alongside File.name, and parse for separators 2013-09-10 00:44:38 +0000 1 1 1 Unclassified WebAppsWG File API unspecified PC All RESOLVED FIXED P2 normal --- 1 arun arun annevk public-webapps public-webapps-bugzilla oldest_to_newest 93004 0 arun 2013-09-04 20:17:13 +0000 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. 93128 1 arun 2013-09-06 17:01:09 +0000 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. 93129 2 annevk 2013-09-06 17:05:44 +0000 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. 93182 3 arun 2013-09-10 00:44:38 +0000 Fixed, but strictly along the lines of Comment 1. We're not doing File.rawName.