In the process of trying to migrate all my blog posts over from a custom solution to my Dropbox powered one, I discovered an interesting defect associated with the way Dropbox detects mime types.
I have a directory with 102 files in them, all of them of the markdown (sort of)
variety. 94 of them, when inspected through the Dropbox API, present an
expected text/plain mime type.
However the other 8 files were transmitting a text/x-lisp or text/x-pascal
mime type, which as a result prevented them from being uploaded/synced properly
within my application. Why was the mime type being rendered as such, despite
them containing simple Markdown? I have no idea. Maybe Dropbox's mime type
interpreter is seeing something in those documents that make it believe it's a
Lisp or Pascal file.
When I check the mime type on OSX through the command:
file --mime filename
I get what I would assume: text/plain
I'm not sure where the disconnect is. It could be on Dropbox's side. It could be
during the transmission of the file. But something to consider when filtering or
using the mime property through the
Dropbox API.