Does HTML5 allow drag-drop upload of folders or a folder tree?

Question

I haven't seen any examples that do this. Is this not allowed in the API spec?

I am searching for an easy drag-drop solution for uploading an entire folder tree of photos.

Solution 1

It's now possible, thanks to Chrome >= 21.

function traverseFileTree(item, path) {
  path = path || "";
  if (item.isFile) {
    // Get file
    item.file(function(file) {
      console.log("File:", path + file.name);
    });
  } else if (item.isDirectory) {
    // Get folder contents
    var dirReader = item.createReader();
    dirReader.readEntries(function(entries) {
      for (var i=0; i<entries.length; i++) {
        traverseFileTree(entries[i], path + item.name + "/");
      }
    });
  }
}

dropArea.addEventListener("drop", function(event) {
  event.preventDefault();

  var items = event.dataTransfer.items;
  for (var i=0; i<items.length; i++) {
    // webkitGetAsEntry is where the magic happens
    var item = items[i].webkitGetAsEntry();
    if (item) {
      traverseFileTree(item);
    }
  }
}, false);

More info: https://protonet.info/blog/html5-experiment-drag-drop-of-folders/

Solution 2

Unfortunately none of the existing answers are completely correct because readEntries will not necessarily return ALL the (file or directory) entries for a given directory. This is part of the API specification (see Documentation section below).

To actually get all the files, we'll need to call readEntries repeatedly (for each directory we encounter) until it returns an empty array. If we don't, we will miss some files/sub-directories in a directory e.g. in Chrome, readEntries will only return at most 100 entries at a time.

Using Promises (await/ async) to more clearly demonstrate the correct usage of readEntries (since it's asynchronous), and breadth-first search (BFS) to traverse the directory structure:

// Drop handler function to get all files
async function getAllFileEntries(dataTransferItemList) {
  let fileEntries = [];
  // Use BFS to traverse entire directory/file structure
  let queue = [];
  // Unfortunately dataTransferItemList is not iterable i.e. no forEach
  for (let i = 0; i < dataTransferItemList.length; i++) {
    queue.push(dataTransferItemList[i].webkitGetAsEntry());
  }
  while (queue.length > 0) {
    let entry = queue.shift();
    if (entry.isFile) {
      fileEntries.push(entry);
    } else if (entry.isDirectory) {
      queue.push(...await readAllDirectoryEntries(entry.createReader()));
    }
  }
  return fileEntries;
}

// Get all the entries (files or sub-directories) in a directory 
// by calling readEntries until it returns empty array
async function readAllDirectoryEntries(directoryReader) {
  let entries = [];
  let readEntries = await readEntriesPromise(directoryReader);
  while (readEntries.length > 0) {
    entries.push(...readEntries);
    readEntries = await readEntriesPromise(directoryReader);
  }
  return entries;
}

// Wrap readEntries in a promise to make working with readEntries easier
// readEntries will return only some of the entries in a directory
// e.g. Chrome returns at most 100 entries at a time
async function readEntriesPromise(directoryReader) {
  try {
    return await new Promise((resolve, reject) => {
      directoryReader.readEntries(resolve, reject);
    });
  } catch (err) {
    console.log(err);
  }
}

Complete working example on Codepen: https://codepen.io/anon/pen/gBJrOP

FWIW I only picked this up because I wasn't getting back all the files I expected in a directory containing 40,000 files (many directories containing well over 100 files/sub-directories) when using the accepted answer.

Documentation:

This behaviour is documented in FileSystemDirectoryReader. Excerpt with emphasis added:

readEntries()
Returns a an array containing some number of the directory's entries. Each item in the array is an object based on FileSystemEntry—typically either FileSystemFileEntry or FileSystemDirectoryEntry.

But to be fair, the MDN documentation could make this clearer in other sections. The readEntries() documentation simply notes:

readEntries() method retrieves the directory entries within the directory being read and delivers them in an array to the provided callback function

And the only mention/hint that multiple calls are needed is in the description of successCallback parameter:

If there are no files left, or you've already called readEntries() on this FileSystemDirectoryReader, the array is empty.

Arguably the API could be more intuitive as well.

Related:

• johnozbay comments that on Chrome, readEntries will return at most 100 entries for a directory (verified as Chrome 64).
• Xan explains the correct usage of readEntries quite well in this answer (albeit without code).
• Pablo Barría Urenda's answer correctly calls readEntries in a asynchronous manner without BFS. He also notes that Firefox returns all the entries in a directory (unlike Chrome) but we can't rely on this given the specification.

Solution 3

This function will give you a promise for array of all dropped files, like <input type="file"/>.files:

function getFilesWebkitDataTransferItems(dataTransferItems) {
  function traverseFileTreePromise(item, path='') {
    return new Promise( resolve => {
      if (item.isFile) {
        item.file(file => {
          file.filepath = path + file.name //save full path
          files.push(file)
          resolve(file)
        })
      } else if (item.isDirectory) {
        let dirReader = item.createReader()
        dirReader.readEntries(entries => {
          let entriesPromises = []
          for (let entr of entries)
            entriesPromises.push(traverseFileTreePromise(entr, path + item.name + "/"))
          resolve(Promise.all(entriesPromises))
        })
      }
    })
  }

  let files = []
  return new Promise((resolve, reject) => {
    let entriesPromises = []
    for (let it of dataTransferItems)
      entriesPromises.push(traverseFileTreePromise(it.webkitGetAsEntry()))
    Promise.all(entriesPromises)
      .then(entries => {
        //console.log(entries)
        resolve(files)
      })
  })
}

Usage:

dropArea.addEventListener("drop", function(event) {
  event.preventDefault();

  var items = event.dataTransfer.items;
  getFilesFromWebkitDataTransferItems(items)
    .then(files => {
      ...
    })
}, false);

NPM package: https://www.npmjs.com/package/datatransfer-files-promise

Usage example: https://github.com/grabantot/datatransfer-files-promise/blob/master/index.html

Solution 4

In this message to the HTML 5 mailing list Ian Hickson says:

HTML5 now has to upload many files at once. Browsers could allow users to pick multiple files at once, including across multiple directories; that's a bit out of scope of the spec.

(Also see the original feature proposal.) So it's safe to assume he considers uploading folders using drag-and-drop also out of scope. Apparently it's up to the browser to serve individual files.

Uploading folders would also have some other difficulties, as described by Lars Gunther:

This […] proposal must have two checks (if it is doable at all):

1. Max size, to stop someone from uploading a full directory of several hundred uncompressed raw images...

2. Filtering even if the accept attribute is omitted. Mac OS metadata and Windows thumbnails, etc should be omitted. All hidden files and directories should default to be excluded.

Solution 5

Now you can upload directories with both drag and drop and input.

<input type='file' webkitdirectory >

and for drag and drop(For webkit browsers).

Handling drag and drop folders.

<div id="dropzone"></div>
<script>
var dropzone = document.getElementById('dropzone');
dropzone.ondrop = function(e) {
  var length = e.dataTransfer.items.length;
  for (var i = 0; i < length; i++) {
    var entry = e.dataTransfer.items[i].webkitGetAsEntry();
    if (entry.isFile) {
      ... // do whatever you want
    } else if (entry.isDirectory) {
      ... // do whatever you want
    }
  }
};
</script>

Resources:

http://updates.html5rocks.com/2012/07/Drag-and-drop-a-folder-onto-Chrome-now-available

View more solutions

Comments

[Nicolas Raoul]

@MoB: maybe it is some kind of pointer indeed. But since the actual file is on the client machine, the server machine will not be able to do anything with this pointer, of course.

[Nicolas Raoul]

Even 2 years later, IE and Firefox don't seem to be willing to implement this.

[CJT3]

Hmmm, I agree on point 2... but only as long as there is a way for the web developer to determine if they want to enable the upload of hidden files - as there is always the potential that a hidden file could be operative to the use of the uploaded folder. Especially if the folder is a full on document split into multiple parts like a final cut file might be.

[Ciro Santilli OurBigBook.com]

Disagree with out of scope: this is a cause of incompatibilities for something many people want to do, so it should be specified.

[Ciro Santilli OurBigBook.com]

question on how to use on Chrome: stackoverflow.com/questions/5826286/…

[user2284570]

@ChristopherBlum : How do to the same for download without using zipped folders ?

[user2284570]

Is it possible to do the same for downloading without using compressed folders ?

[dforce]

Now, for Firefox as well: stackoverflow.com/a/33431704/195216 It shows folder uploading via drag'n'drop and via dialog in chrome and firefox!

[bebbi]

Wow. Telling from the W3C Note at that link, this is indeed not continued. What is the basis of the assumption that it has failed to get any traction?

[basarat]

@bebbi no other browser vendors implemented it

[keithwill]

Updated link to mentioned article: protonet.com/blog/html5-experiment-drag-drop-of-folders

[ZachB]

Edge supports this too.

[RoccoB]

This should be the new accepted answer. It is better than other answers because it returns a promise when complete. But there were a few mistakes: function getFilesWebkitDataTransferItems(dataTransfer) should be function getFilesWebkitDataTransferItems(items), and for (entr of entries) should be for (let entr of entries).

[johnozbay]

Important warning: The code in this answer is limited to 100 files in a given directory. See here : bugs.chromium.org/p/chromium/issues/detail?id=514087

[xlm]

Won't actually get all the files in a directory (for Chrome it will only return 100 entries in a directory). Spec stipulates the need to call readEntries repeatedly until it returns an empty array.

[xlm]

@PabloBarríaUrenda comment is not true; his issue is likely referring to his question: stackoverflow.com/questions/51850469/… which he solved/realised readEntries can't be called if another call of readEntries is still being run. The DirectoryReader API design isn't the best

[xlm]

@johnozbay it's unfortunate that more people picked up your important warning, and it's not necessarily a Chromium issue since the spec says readEntries won't return all the entires in a directory. Based on the bug link your provided, I've written up a complete answer: stackoverflow.com/a/53058574/885922

[Pablo Barría Urenda]

@xlm yes, indeed you are correct. I had posted this while I myself was puzzled by the issue, but I eventually resolved it (and forgot about this comment). I have now deleted the confusing comment.

[johnozbay]

Thanks a lot for the shout-out, and getting this content out there. SOF needs more fantastic members like yourself! ✌🏻

[Jawed Warsi]

The comment above about "limited to 100 files in a given directory" is invalid per the comments on the bug that is linked to.

[xlm]

@MichaelRush The comment IS valid. From the bug issue page: the dev comments that "[t]he key is continuing to call readEntries as long as it keeps returning items". Sure the root cause was readEntries clobbering each other (same as in stackoverflow.com/a/51850683/885922) but it still stands that readEntries will not necessarily return all entries in a directory. The specification even provides this (see stackoverflow.com/a/53058574/885922)

[xlm]

I appreciate that @johnozbay I'm just concerned that it seems that many users are overlooking this small but significant fact re: specification/API and this edge case (100+ files in a directory) isn't that unlikely. I only realised it when I wasn't getting back all the files I expected. Your comment should have been answer.

[Jawed Warsi]

@xlm Ok, thanks for the clarification! I see the issue now, a potentially misleading implementation. Also thanks for your work demonstrating a working solution.

[grabantot]

@xlm Updated npm package. Now it handles >100 entries.

[Matteo]

How to get the file size?

[Iskren Ivov Chernev]

To get all relevant metadata (size, lastModified, mime type), you need to convert all FileSystemFileEntry to File, via the file(successCb, failureCb) method. If you also need the full path, you should take that from fileEntry.fullPath (file.webkitRelativePath will be just the name).

[Kim Nyholm]

Working great. Ported to Vue jsfiddle.net/KimNyholm/xua9kLny

[Siddhartha Chowdhury]

Very helpful! Thanks for the solution. So far this is the most precise and clean one. This should be new accepted answer, I agree.

[happybeing]

This seems like the best answer, but does not work for me in Chromium 86. Seems to work fine in Firefox. In Chromium it will upload selections containing files, but nothing is uploaded for a directory because readEntriesPromise() returns an empty array.

[xlm]

@happybeing I just tested the Codepen with Chrome 86 and it's still working. We expect readEntriesPromise to return an empty array, eventually. We have to call it in loop (from readAllDirectoryEntries) until it returns an empty. Then we know we have collected all the entries (files and subdirectories) in entries. readAllDirectoryEntries itself must be called using BFS or similar (e.g. getAllFileEntries) since directories can contain subdirectories and those can further subdirectories and so on. If you're still stuck please post a new Q and I'll try to take a look

[Qwerty]

Interesting, the same code runs in the codepen, but not in my local html file. When I upload the very same file to my http server, it then works. No error in console.

[Andrey]

Does it makes sense to convert file entries into the actual file objects right away when they are iterated within getAllFileEntries, thus turning getAllFileEntries into a getAllFiles (after all, looks like that is the final target for most of use cases)? Or am I missing something?

[xlm]

@Andrey the main issue is that the File object does not enable us to readily handle the case where we have a directory and wish to get its files or sub-directories. This is the reason why we call dataTransferItemList[i].webkitGetAsEntry() instead of dataTransferItemList[i].getAsFile()

[Andrey]

@xlm, got it, thanks. Could you say, in your opinion, how heavy, performance-wise, the operation of converting a file entry into a File? I.e. if I have hundreds or thousands files, could it be a problem to convert them to File objects? Though I understand that to upload them, they are needed to be converted to File anyway...

[xlm]

Converting to File doesn't appear to be intensive so I wouldn't worry about that operation. I've got this code in production and it easily handles tens of thousands of files. In fact my test harness was 40,000 files arbitrarily nested. Uploading of the content itself will of course depend on file size, disk, network etc.

[Rvach.Flyver]

I've faced interesting behaviour I cannot understand. I'm using react-dropzone which internally uses file-selector package (I'll call it ORIGINAL). Unfortunately it does not handle empty folders, so I started to play with its fork github.com/Nerlin/file-selector (lets say FORKED). It appears that after I do reading with ORIGINAL file-selector, I cannot redo reading with FORKED one using the same dataTransfer.items. Somehow items are modified after read (but I do not see any changes in ORIGINAL codebase) as item.kind appears empty string and calling webkitGetAsEntry returns null.

[Rvach.Flyver]

Does smb know why reading files and directories cannot be done twice?

[Cao Shouguang]

This is perfect! Thanks thanks thanks!