FileSystem API Comments

Hello,

I'm with the IE Platform team at Microsoft. We have a few comments on the latest editor's draft of the newly proposed FileSystem API [1].

1.1 Use cases (3. Audio/Photo editor with offline access or local cache for speed)

  * Edited files should be accessible by other client-side applications
     - Having the sandboxed file system share its contents between all apps would allow apps to tamper with the files of another app. This could result in corrupted files and perhaps an invalid state for some apps that expect certain contents to exist in a file. This makes us wonder: should we warn users about files that are being opened and written to? If an app is just doing a read, can it open a file or directory without the user's permission, or could this pose a possible issue as well? Also, is the Quota Management API going to be a dependency? It's unclear what we would do with regards to requesting permission to access files. Will this spec be responsible for defining what questions/permission inquiries are presented and when they are presented to the user? For example, what happens when one file is locked for use by a different application? Is the user notified and given the option to open a read-only copy of that file?


3. The Directory Interface

  * Change events
     - I would like to revisit the discussion on apps getting notifications of changes to files/directories. There are many scenarios where an application would want to react to renames/moves of a file/directory. There would also be value in being notified of a change to a directory's structure. If an app has a file browser that allows a user to select files and/or directories and another app makes changes to the sandboxed filesystem, then it would be expected that the first app should be notified and would be able to refresh its directory tree. Otherwise it would require the user to somehow force a refresh which would not be a good user experience since the user would expect the file browser to update on its own.

  * removeDeep() & move()
     - Do these support links or junctions? If not, what is the expected behavior?

  * enumerate()
     - It would be useful to have pre-filtering support for the following: file/directory, ranges, wildcard search. Currently we would be forced to enumerate the entire set and manually filter out the items we want from the result set.
         - Callers often know exactly whether or not they want to enumerate files or folders. For example, an image upload service may only be interested in the files present in a directory rather than all of its directories. Perhaps it would be useful to have enumerateFiles() and enumerateDirectories() for this purpose? Or we could have another argument for enumerate() that is an enum ("directory", "file").
         - Supporting optimized pagination of large directories. We could have arguments for a starting index and length we would be able to specify a range of items to retrieve within the result set.
         - Supporting the wildcard character to pre-filter a list of files/directories (e.g. *.jpg).

4. The FileHandle Interface

  * FileHandles
     - Is this basically going to be the first to get the handle gets to use it and all subsequent calls need to wait for the file handle to become available again? Are there more details about the locking model used here?

  * Auto-closing of FileHandles
     - This may cause confusion as it does not match the common developer mental model of a file handle which is "opened" and then available for use until it's "closed". Perhaps it would be advantageous to have an explicit close function as part of the FileHandle interface? With the current behavior there can be overhead with the unintended closure of the FileHandle that would require a developer to continuously open/close a FileHandle. The currently defined behavior assumes that a developer is done with all their file manipulations when they have completed a promise chain. However, a developer may want to keep the FileHandle open to be used elsewhere at some other point in time that is not related to the current promise chain. An example of the usefulness of having an explicit close function is if you were to implement a word processor and wanted to lock down the file that it currently has open for the period of its editing. This way you are free to continue operating on that file for the duration that it is open, protecting the file from other processes, and not having to undergo the costly setup and teardown of a file handle.

  * AbortableProgressPromise
     - It is not clear how a developer would define the abort callback of an AbortableProgressPromise. It seems that the user agent would be responsible for setting the abort callback since it instantiates and returns the AbortableProgressPromise.


5. The FileHandleWritable Interface

  * write() & flush()
     - It might be useful to have support for "transacted" streams where the caller can write to a copy of the file and then have it atomically replaced: swap the old file with the new one and then delete the old file. This reduces the opportunity for an app crash to lead to a corrupted file on disk; it would be corrupted without transacted streams if the app crashes during save. The transacted streams could be handled during the (automated) flush where the user agent would write to a temp file and atomically replace the intended file.

  * flush()
     - This is costly functionality to expose and is likely to be overused by callers. It would be beneficial to automatically flush changes to disk by allowing the default file write behavior by the OS. For example, on Windows, we would leave it up to the filesystem cache to determine the best time to flush to disk. This is non-deterministic from the app's point of view, but the only time it is a potential problem is when there's a hard power-off. Most apps should not be concerned with this; only apps that have very high data reliability requirements would need the granular control of flushing to disk. In those cases a developer should use IndexedDB. So we should consider obscuring this functionality since it's not a common requirement and has a performance impact if it's widely used.

6. FileSystem Configuration Parameters

  * Dictionary DestinationDict
     - The DestinationDict seems to exist to facilitate the renaming of a directory in conjunction with a move. However, the same operation is done differently for files which makes the functionality non-uniform. Perhaps we can add a rename() function to make it more intuitive?


Thank you,
Ali