This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 23160 - Add a File.rawName attribute on File alongside File.name, and parse for separators
Summary: Add a File.rawName attribute on File alongside File.name, and parse for separ...
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: File API (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Arun
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-04 20:17 UTC by Arun
Modified: 2013-09-10 00:44 UTC (History)
2 users (show)

See Also:

Attachments

Description Arun 2013-09-04 20:17:13 UTC 
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.
Comment 1 Arun 2013-09-06 17:01:09 UTC 
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.
Comment 2 Anne 2013-09-06 17:05:44 UTC 
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.
Comment 3 Arun 2013-09-10 00:44:38 UTC 
Fixed, but strictly along the lines of Comment 1.  We're not doing File.rawName.