- From: Charles Pritchard <chuck@jumis.com>
- Date: Wed, 12 Jan 2011 15:37:38 -0800
- To: Eric Uhrhane <ericu@google.com>
- CC: Glenn Maynard <glenn@zewt.org>, public-webapps@w3.org
On 1/11/2011 2:33 PM, Eric Uhrhane wrote: > Actually, it's not just that Linux users now have to worry about > Windows rules; Windows users also have to worry about Linux rules, in > particular the path length limitation, which is 255 bytes on Linux but > 255 UTF-16 code points on Windows. WebKit is addressing the current issue in active releases (a 255 byte path length limit): http://code.google.com/p/chromium/issues/detail?id=63574 Those very-short length limitations are really frustrating. >> It's also a pain for backing up files, eg. copying "moon rock?.jpg" to >> "moon rock?.jpg~", and for "safe writes", writing to "moon >> rock?.jpg.new" and then renaming the finished file over the original. > > I'm looking into the encoding problems now, and will respond later. > In general we should be able to read any such file already, at the > very least by enumerating the directory to get the FileEntry, but > creating files with valid names may be tricky. A lot of these use cases really would be better served by IndexedDB. No issues with naming, no issues with file counts/inodes, performance, etc. Blobs can be stashed nicely, and so forth. > However, an obvious expansion of this API which we've talked a lot > about is the ability to expose other "mount points" to the browser. > For example, a trusted app might be granted access to "My Photos" or > another similar directory. There the majority of the files are > expected to be created by apps outside of the browser, and you run > into the thumbnail problem you describe above, where a > read-modify-write of a path or even a copy operation can inadvertently > create a file path that's banned by the API, but is legal on the host > system. > The <input type="file" webkitdirectory> experiment has opened up some room for the idea of mount points. Perhaps, further exploration there would be helpful.
Received on Wednesday, 12 January 2011 23:38:02 UTC