sathomas
commented
10 years ago After a bit of research and console debugging, I've got a few ideas on how to handle file packages.
File Packages and Firefox
Since Firefox is (at the moment) philosophically opposed to the HTML5 FileSystem API, the options are somewhat limited. The following steps, though, are possible.
- Keep a list of problematic file extensions (e.g.
.pages,.key, and.numbers). - When a file is dropped
- and its extension is on the list,
- and it has a size of 0 bytes,
- and the user's OS is OS X,
- Then show a more specific error notification. (Something like "For folders or OS X documents, try uploading a compressed version instead.")
File Packages and Safari
For Safari we can accept file packages for upload. We just need to append a .zip extension. The approach could go something like.
- When a file is dropped
- and its extension is on the list,
- and it has a non-zero size,
- and it's content is not accessible (which appears to be true since Safari only creates the archive during transit),
- Then infer that the file is a package
- and append a
.zipextension - and include a note in the content object's description. (Something like "Compressed version of Presentation.")
- and append a
File Packages and Chrome
The approach for Chrome is similar to Firefox but with different details
- When a folder is dropped
- and its extension is on the list,
- and the user's OS is OS X,
- and the folder contains a file with the
.plistextension,
- Then generate an error instead of accepting the folder and show a specific error notification. (Something like "For folders or OS X documents, try uploading a compressed version instead.")
Because Chrome does support the FileSystem API, there is an alternative. (Normally I'd hesitate to recommend it in case I ended up having to implement it, but I'm pretty confident that no one will seriously consider it.) For completeness:
- Same as above except, instead of generating an error, retrieve the folder's contents in the browser and create a
.ziparchive there. Then follow the same steps as for Safari.
There are obvious edge cases that could fool the approaches described above, but I expect they'd be pretty rare.
nicolaasmatthijs
OS X allows certain directories (file packages) to be presented to users as single files in the the Finder. Many OS X applications (Keynote, Pages, Numbers, ...) use file packages for individual documents. If a user attempts to upload a file package to the OAE, the behavior is browser-dependent, but in no case is it good. The following behaviors are based on the pending pull request https://github.com/oaeproject/3akai-ux/pull/3781.
Safari
Safari recognizes file packages as documents, creates a
.ziparchive of the directory contents, and uploads that.ziparchive as a single file. It does not, however, change the name of the file package to add a.zipextension. When an OAE user downloads this uploaded file, it is downloaded as a.ziparchive but retains the name of the original file package. (For example, what really should be namedPresentation.key.zipis downloaded asPresentation.key.) The OS X Finder attempts to treat the resulting download as a file package instead of an archive, and the corresponding app fails to open it.Firefox
Firefox treats file packages exactly as regular directories (folders), which is to say it presents them to JavaScript as zero-length files. The OAE rejects files without content and does not upload them.
Chrome
Chrome treats file packages exactly as regular directories (folders), which is to say it allows JavaScript to traverse the file system and locate individual files within the package. The OAE thus uploads many (potentially hundreds) of useless individual files instead of the single document the user expects. Here's an example of the individual files that comprise a single Keynote presentation.