You could cheat by providing a 0 byte file "folder/nul" and define it to not be created. On Windows (dos), such a file is used to test for the existence of a directory, and it's illegal to create a file by that name.
On 11/15/11, Jonas Sicking <[email protected]> wrote: > On Tue, Nov 15, 2011 at 1:01 AM, Kinuko Yasuda <[email protected]> wrote: >> Hi, >> >> We'd like to propose (and experiment in Webkit/chromium) exposing >> dropped files/folders as {File,Directory}Entry defined in FileSystem >> API [1] for better folders/files drag-and-drop support. >> >> [1] File API: Directories and System http://www.w3.org/TR/file-system-api/ >> >> Usage scenario: >> Many sites have 'upload your files' feature, like for >> your photo images. HTML5 allows you to do this via >> <input type="file" multiple> or drag-and-drop feature, >> but the current solution does not provide clean solution >> for cases with folders, files/folder mixed cases, or folders >> with subfolders cases. >> >> For context, back then we have proposed (and implemented) >> 'directory' attribute for <input type=file> specifically to upload >> a directory, but the approach does not provide useful information >> to webapps about which file comes from which folder, neither >> does it allow apps to control how and when to enumerate >> directories (e.g. app cannot show progress meter etc even >> the enumerating part takes long time). >> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-April/025764.html >> >> Proposal: >> Add a new field 'entries' to <input type=files> element >> and to DataTransfer object, and populate the field with >> file or directory 'Entries' defined in FileSystem API [1] >> upon file selection or drop events. >> >> Since FileSystem API naturally supports tree-structured >> folder hierarchy, Entry object exposes handy fields like 'isFile' >> and 'isDirectory', and allows webapps to recursively walk over >> the nested entries in subfolders via ReadDirectory() method. >> >> This approach allows webapps to directly interact >> with the local folder structure, and also allows >> them to control the enumerating part so that >> the apps can show nice progress meter if they want. >> >> Security notes: >> The Entries exposed by this feature must be >> read-only and isolated in a special temporary >> filesystem so that the webapps cannot access any >> other folders outside the dropped ones. >> >> Example: >> When I choose or drag-and-drop a set of folders >> in the photos folder like: >> >> /Users/kinuko/Photos/trip/1.jpg >> /Users/kinuko/Photos/trip/2.jpg >> /Users/kinuko/Photos/trip/3.jpg >> /Users/kinuko/Photos/halloween/a.jpg >> /Users/kinuko/Photos/halloween/b.jpg >> /Users/kinuko/Photos/tokyo/1.jpg >> /Users/kinuko/Photos/tokyo/2.jpg >> ... >> >> Via the new 'entries' field the site can access each >> subfolder 'trip' or 'halloween' by scripting, and can >> properly organize and process pictures using the local >> folder structure. >> >> We can think of similar interesting usage scenarios >> like local-cloud sync app or bulk 'importer', e.g. importing >> local source directory to cloud IDE etc. >> >> What are your thoughts about adding folder support using DirectoryEntry? > > Adding FileEntry/DirectoryEntry seems confusing since those are > generally writable in the FileSystem API spec, right? Additionally, > DirectoryEntry is asynchronous, which makes enumerating the tree more > painful. > > The way we were planning on exposing this in Gecko is to simply set > File.name to the full relative path to the folder dropped. So in the > example above, if the user dropped the "Photos" folder from the > example above on a page, we'd make .files return a list of 7 Files, > with names like "Photos/trip/1.jpg", "Photos/trip/2.jpg", > "Photos/trip/3.jpg", "Photos/halloween/a.jpg", etc. > > This has the advantage of being a smaller and simpler API. > > The only functionality that I can think of which we'd loose is the > ability to deal with empty directories since they simply wouldn't show > up in the .files list. But I'm not sure there are use cases for that. > As a data point, mercurial and git has both decided not to support > empty directories. > > / Jonas > > / Jonas > -- Sent from my mobile device
