<CAACrNNf9SDTK3FOWhs9yFRNpT=cv=psnenb+kHUkEpkO9Rf8KA@mail.gmail.com>
Current votes: None.
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 <jonas@sicking.cc> wrote:
> On Tue, Nov 15, 2011 at 1:01 AM, Kinuko Yasuda <kinuko@chromium.org> wrot=
e:
>> 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-ap=
i/
>>
>> Usage scenario:
>> =C2=A0 Many sites have 'upload your files' feature, like for
>> =C2=A0 your photo images. =C2=A0HTML5 allows you to do this via
>> =C2=A0 <input type=3D"file" multiple> or drag-and-drop feature,
>> =C2=A0 but the current solution does not provide clean solution
>> =C2=A0 for cases with folders, files/folder mixed cases, or folders
>> =C2=A0with subfolders cases.
>>
>> =C2=A0For context, back then we have proposed (and implemented)
>> =C2=A0'directory' attribute for <input type=3Dfile> specifically to uplo=
ad
>> =C2=A0a directory, but the approach does not provide useful information
>> =C2=A0to webapps about which file comes from which folder, neither
>> =C2=A0does it allow apps to control how and when to enumerate
>> =C2=A0directories (e.g. app cannot show progress meter etc even
>> =C2=A0the enumerating part takes long time).
>> =C2=A0http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-April/025=
764.html
>>
>> Proposal:
>> =C2=A0 Add a new field 'entries' to <input type=3Dfiles> element
>> =C2=A0and to DataTransfer object, and populate the field with
>> =C2=A0 file or directory 'Entries' defined in FileSystem API [1]
>> =C2=A0upon file selection or drop events.
>>
>> =C2=A0 Since FileSystem API naturally supports tree-structured
>> =C2=A0folder hierarchy, Entry object exposes handy fields like 'isFile'
>> =C2=A0and 'isDirectory', and allows webapps to recursively walk over
>> =C2=A0the nested entries in subfolders via ReadDirectory() method.
>>
>> =C2=A0 This approach allows webapps to directly interact
>> =C2=A0 with the local folder structure, and also allows
>> =C2=A0 them to control the enumerating part so that
>> =C2=A0 the apps can show nice progress meter if they want.
>>
>> Security notes:
>> =C2=A0The Entries exposed by this feature must be
>> =C2=A0read-only and isolated in a special temporary
>> =C2=A0filesystem so that the webapps cannot access any
>> =C2=A0other folders outside the dropped ones.
>>
>> Example:
>> =C2=A0 When I choose or drag-and-drop a set of folders
>> =C2=A0 in the photos folder like:
>>
>> =C2=A0 =C2=A0 /Users/kinuko/Photos/trip/1.jpg
>> =C2=A0 =C2=A0 /Users/kinuko/Photos/trip/2.jpg
>> =C2=A0 =C2=A0 /Users/kinuko/Photos/trip/3.jpg
>> =C2=A0 =C2=A0 /Users/kinuko/Photos/halloween/a.jpg
>> =C2=A0 =C2=A0 /Users/kinuko/Photos/halloween/b.jpg
>> =C2=A0 =C2=A0 /Users/kinuko/Photos/tokyo/1.jpg
>> =C2=A0 =C2=A0 /Users/kinuko/Photos/tokyo/2.jpg
>> =C2=A0 =C2=A0 ...
>>
>> =C2=A0Via the new 'entries' field the site can access each
>> =C2=A0subfolder 'trip' or 'halloween' by scripting, and can
>> =C2=A0properly organize and process pictures using the local
>> =C2=A0folder structure.
>>
>> =C2=A0We can think of similar interesting usage scenarios
>> =C2=A0like local-cloud sync app or bulk 'importer', e.g. importing
>> =C2=A0local 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
>
--=20
Sent from my mobile device