5 ms·

This is already how HTTP works. Storing the MIME type separately is definitely a good thing. This isn't the only way you do it. You start by checking the MIME

This is already how HTTP works. Storing the MIME type separately is definitely a good thing. This isn't the only way you do it. You start by checking the MIME type and then fall back to one of our crude detection mechanisms, like guessing what the file type is based on extension. We already store plenty of metadata with files--permissions and timestamps for starters. The metadata is sometimes lost when you transfer to another system. That's OK... you can repair the metadata. Given that this metadata is already present in the HTTP protocol, it's present in files embedded in email messages, and given that extended attributes are supported by many different filesystems, I think this solution is completely workable. You could make the argument that since we spend so much time interacting with files over HTTP, that having a MIME type in the metadata is actually the common way to do things.

lmm 6y ago
What is it that makes the MIME type good and reliable and the file extension crude and unreliable? In my experience it's the opposite - the file extension is much more user-visible, much more likely to be preserved when the file is transferred, and so more reliable than any other way of storing the file type. HTTP and email were overly influenced by the unix tradition in which file extensions are seen as less important, but nowadays the file extension is the most widely supported "extended attribute" that a file might have - why use a less reliable version of the same thing?
- klodolph 6y ago
  One huge problem is that the space of available prefixes is just too damn small. It's tiny. This may be fine for you if you only deal with a few mundane filetypes like plain text, PNG, etc. However, it's very easy to end up in a situation where multiple applications share the file extension. I've run into it all too often. So you need something to disambiguate. I can understand that if you've never personally run into this problem, it may seem unimportant. It is extremely frustrating to work with two different files with the same extension on a regular basis.
  - iforgotpassword 6y ago
    > However, it's very easy to end up in a situation where multiple applications share the file extension. I've run into it all too often. Care to share some examples? I've very rarely had this problem when some specific program chose to use something like .dat as the extension, but I doubt someone making this decision would have picked a sensible mime type either. Then you mention http already solves this problem. Great. Now you only need to fix the remaining five trillion protocols used to transfer files that don't. If you're old enough you might know the unix haters handbook. It also made fun of this problem and smarty-pants explained how the next version of macos will strictly store any metadata, such as mime type, separately in the file system meta data and not in the file(name) anymore. I think they even gave the size of an image as an example. Thirty years later and this is still what macos does; Jpeg files still end in jpg and contain exif data. Metadata goes in the file, file type is the same. That's the only sane way to get this to work in an interoperable way. It's the least common denominator, since you always have these two, no matter the environment. For anything else, the ship has sailed.
    - nyanpasu64 6y ago
      File extensions are flawed. The .spc file extension is used for both cryptographic certificates and SPC700 audio files. Every time I setup a Windows machine and want to play .spc music, I have to reassociate .spc with a music player. Every time I setup a Linux KDE machine and want to play .spc music, I associate .spc to a new MIME type in my KDE settings, and file picks up this new file type, but xdg-open and KDE insists on treating it as application/pkcs7-mime. MIME types are flawed in a world that only stores file extensions. On Android, you can only register apps as handling specific file MIME types, not file extensions. And for a non-mainstream file extension like .spc, every file browser app synthesizes a different MIME type (which may be blank in some cases).
      - shawnz 6y ago
        Not to diminish the argument about file extensions having a too-small namespace, but... why not just save your SNES music in wav or flac files or something? Wouldn't that be a simpler solution to manage in many ways (not just because of file extensions)?
icedchai 6y ago
And where does the MIME type originate? With many web servers, its based on file extensions or magic numbers...
- klodolph 6y ago
  Sure, static web servers serving files from a standard filesystem. Does it apply to dynamically generated content? No. Does it apply to key-value stores like S3 and GCS? No.
  - icedchai 6y ago
    Seems simpler just to use extensions or magic #s. Most normal users don't understand metadata.
    - klodolph 6y ago
      Most users don’t understand file extensions.
gorgoiler 6y ago
MIME type feels as if it is as intrinsic a property as something like file size. It is a property of the data itself, not a property that a person chooses for the file like, say, the file name. Could you give an example where one would want to choose the MIME type of some data, from a selection of options?
- klodolph 6y ago
  "It is a property of the data itself," meaning, it's metadata. I'm in favor of preserving this metadata. You will sometimes need to change the MIME type of something. For example, if you use a text editor to create an HTML file, you'll want to change the MIME type to text/html. It's also nice to be able to mark *.h files as containing C or C++ code.
  - gorgoiler 6y ago
    It seems like you’ve misunderstood me? MIME-type is an intrinsic property which can be derived from the data itself. I have a cat. I can derive that it is a cat when the situation requires it. I don’t need to have a metadata label attached to it, in my own handwriting, saying “cat”.
    - hibbelig 6y ago
      I argue that it’s not possible to determine the mime type of a file from its contents. For example the content could be malformed. An editor or IDE should still highlight it so the user can find the syntax error. Of course, for some files it is possible. But we need the metadata for the other files.
    - kaba0 6y ago
      Well, they are bytes, not a cat. It can be interpreted as an image (in multiple formats) or text or whatever, so I don’t think this metaphor is apt.
- jcelerier 6y ago
  > It is a property of the data itself, not a property that a person chooses for the file like, say, the file name. I entirely disagree. If I have an empty .json or empty .bin or empty .txt I expect a different behaviour in the software that I am opening the file with, even if in all cases the actual data is zero bytes. More generally file formats can be polyglots: https://github.com/Polydet/polyglot-database https://github.com/Polydet/polyglot-database

lmm 6y ago

What is it that makes the MIME type good and reliable and the file extension crude and unreliable? In my experience it's the opposite - the file extension is much more user-visible, much more likely to be preserved when the file is transferred, and so more reliable than any other way of storing the file type. HTTP and email were overly influenced by the unix tradition in which file extensions are seen as less important, but nowadays the file extension is the most widely supported "extended attribute" that a file might have - why use a less reliable version of the same thing?

klodolph 6y ago
One huge problem is that the space of available prefixes is just too damn small. It's tiny. This may be fine for you if you only deal with a few mundane filetypes like plain text, PNG, etc. However, it's very easy to end up in a situation where multiple applications share the file extension. I've run into it all too often. So you need something to disambiguate. I can understand that if you've never personally run into this problem, it may seem unimportant. It is extremely frustrating to work with two different files with the same extension on a regular basis.
- iforgotpassword 6y ago
  > However, it's very easy to end up in a situation where multiple applications share the file extension. I've run into it all too often. Care to share some examples? I've very rarely had this problem when some specific program chose to use something like .dat as the extension, but I doubt someone making this decision would have picked a sensible mime type either. Then you mention http already solves this problem. Great. Now you only need to fix the remaining five trillion protocols used to transfer files that don't. If you're old enough you might know the unix haters handbook. It also made fun of this problem and smarty-pants explained how the next version of macos will strictly store any metadata, such as mime type, separately in the file system meta data and not in the file(name) anymore. I think they even gave the size of an image as an example. Thirty years later and this is still what macos does; Jpeg files still end in jpg and contain exif data. Metadata goes in the file, file type is the same. That's the only sane way to get this to work in an interoperable way. It's the least common denominator, since you always have these two, no matter the environment. For anything else, the ship has sailed.
  - nyanpasu64 6y ago
    File extensions are flawed. The .spc file extension is used for both cryptographic certificates and SPC700 audio files. Every time I setup a Windows machine and want to play .spc music, I have to reassociate .spc with a music player. Every time I setup a Linux KDE machine and want to play .spc music, I associate .spc to a new MIME type in my KDE settings, and file picks up this new file type, but xdg-open and KDE insists on treating it as application/pkcs7-mime. MIME types are flawed in a world that only stores file extensions. On Android, you can only register apps as handling specific file MIME types, not file extensions. And for a non-mainstream file extension like .spc, every file browser app synthesizes a different MIME type (which may be blank in some cases).
    - shawnz 6y ago
      Not to diminish the argument about file extensions having a too-small namespace, but... why not just save your SNES music in wav or flac files or something? Wouldn't that be a simpler solution to manage in many ways (not just because of file extensions)?

icedchai 6y ago

And where does the MIME type originate? With many web servers, its based on file extensions or magic numbers...

klodolph 6y ago
Sure, static web servers serving files from a standard filesystem. Does it apply to dynamically generated content? No. Does it apply to key-value stores like S3 and GCS? No.
- icedchai 6y ago
  Seems simpler just to use extensions or magic #s. Most normal users don't understand metadata.
  - klodolph 6y ago
    Most users don’t understand file extensions.

gorgoiler 6y ago

MIME type feels as if it is as intrinsic a property as something like file size. It is a property of the data itself, not a property that a person chooses for the file like, say, the file name. Could you give an example where one would want to choose the MIME type of some data, from a selection of options?

klodolph 6y ago
"It is a property of the data itself," meaning, it's metadata. I'm in favor of preserving this metadata. You will sometimes need to change the MIME type of something. For example, if you use a text editor to create an HTML file, you'll want to change the MIME type to text/html. It's also nice to be able to mark *.h files as containing C or C++ code.
- gorgoiler 6y ago
  It seems like you’ve misunderstood me? MIME-type is an intrinsic property which can be derived from the data itself. I have a cat. I can derive that it is a cat when the situation requires it. I don’t need to have a metadata label attached to it, in my own handwriting, saying “cat”.
  - hibbelig 6y ago
    I argue that it’s not possible to determine the mime type of a file from its contents. For example the content could be malformed. An editor or IDE should still highlight it so the user can find the syntax error. Of course, for some files it is possible. But we need the metadata for the other files.
  - kaba0 6y ago
    Well, they are bytes, not a cat. It can be interpreted as an image (in multiple formats) or text or whatever, so I don’t think this metaphor is apt.
jcelerier 6y ago
> It is a property of the data itself, not a property that a person chooses for the file like, say, the file name. I entirely disagree. If I have an empty .json or empty .bin or empty .txt I expect a different behaviour in the software that I am opening the file with, even if in all cases the actual data is zero bytes. More generally file formats can be polyglots: https://github.com/Polydet/polyglot-database https://github.com/Polydet/polyglot-database