4 ms·

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 filetyp

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)?
    - nyanpasu64 6y ago
      You can't loop a .wav infinitely (in most music players), you can't mute or isolate channels, change playback speed or pitch or sample interpolation, mute or replace samples, extract score data from the game engine, study how the game engine drives the SPC700 hardware...
      - shawnz 6y ago
        In the same sense there are a lot of advantages to storing your traditional music in the format of its original DAW project files, but wouldn't you agree that's impractical for listening purposes?
        nyanpasu64 6y ago
        It's not impractical, there are certain music players (winamp/foobar2000 plugins, some mobile players) which make managing a library of emulated music as easy as managing regular music in those programs, with orders of magnitude smaller files, and added features like endless looping (which is an important feature to looped game music, but less so in commercial music). One reason it works well is because console sound dumps are self-contained and take up two full orders of magnitude less space than the recordings (because they're taken from consoles with small memories), whereas DAW project files often depend on large sample libraries and external VST plugins, taking up more space than the recordings and often come with setup/DRM issues. There are flaws, like PS1 sound dumps often coming with wrong volumes and echo, but then again most recorded versions of those songs were also generated through inaccurate emulation, then fed through lossy codecs, and some have playback/recording glitches.
    - 6y ago
yjftsjthsd-h 6y ago
> One huge problem is that the space of available prefixes is just too damn small. It's tiny. Can't extensions be long? We're not stuck with 8.3 anymore; AFAIK, "foo.mycustomprogramnamehere" is a 100% valid name.
- scrollaway 6y ago
  They can, but plenty of programs still choose to have a 3 or 4 character extension for their custom formats. The number of video games that have a different .tex for textures ...
  - hawski 6y ago
    I hear you, but they would still say fuck it. They will not think of a proper mime type. What would it be? application/x-studio-game-texture-format-3 If one does not care enough with file extensions they will certainly not care with a mime type.
    - scrollaway 6y ago
      That's not really the point. They likely wouldn't have a content type. File extensions on linux are treated as more of a hint. The point is that if content types were actually stored separately, it would be possible to not rely on detection. Furthermore, it would also be possible to know about a file's content type without it being present on the user's system. You see, in xdg, there is a core database of content types and how to detect them, and more can be installed with programs if they care to do that. But if a file's content type is not in that db, it's unknown to your system entirely. So your system doesn't know that it doesn't know. It's very inconvenient.
      - lmm 6y ago
        Why would adding a new custom mimetype and marking those files as using it be any easier than adding a new custom file extension and renaming those files to use it?

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)?
  - nyanpasu64 6y ago
    You can't loop a .wav infinitely (in most music players), you can't mute or isolate channels, change playback speed or pitch or sample interpolation, mute or replace samples, extract score data from the game engine, study how the game engine drives the SPC700 hardware...
    - shawnz 6y ago
      In the same sense there are a lot of advantages to storing your traditional music in the format of its original DAW project files, but wouldn't you agree that's impractical for listening purposes?
      - nyanpasu64 6y ago
        It's not impractical, there are certain music players (winamp/foobar2000 plugins, some mobile players) which make managing a library of emulated music as easy as managing regular music in those programs, with orders of magnitude smaller files, and added features like endless looping (which is an important feature to looped game music, but less so in commercial music). One reason it works well is because console sound dumps are self-contained and take up two full orders of magnitude less space than the recordings (because they're taken from consoles with small memories), whereas DAW project files often depend on large sample libraries and external VST plugins, taking up more space than the recordings and often come with setup/DRM issues. There are flaws, like PS1 sound dumps often coming with wrong volumes and echo, but then again most recorded versions of those songs were also generated through inaccurate emulation, then fed through lossy codecs, and some have playback/recording glitches.
  - 6y ago

yjftsjthsd-h 6y ago

> One huge problem is that the space of available prefixes is just too damn small. It's tiny. Can't extensions be long? We're not stuck with 8.3 anymore; AFAIK, "foo.mycustomprogramnamehere" is a 100% valid name.

scrollaway 6y ago
They can, but plenty of programs still choose to have a 3 or 4 character extension for their custom formats. The number of video games that have a different .tex for textures ...
- hawski 6y ago
  I hear you, but they would still say fuck it. They will not think of a proper mime type. What would it be? application/x-studio-game-texture-format-3 If one does not care enough with file extensions they will certainly not care with a mime type.
  - scrollaway 6y ago
    That's not really the point. They likely wouldn't have a content type. File extensions on linux are treated as more of a hint. The point is that if content types were actually stored separately, it would be possible to not rely on detection. Furthermore, it would also be possible to know about a file's content type without it being present on the user's system. You see, in xdg, there is a core database of content types and how to detect them, and more can be installed with programs if they care to do that. But if a file's content type is not in that db, it's unknown to your system entirely. So your system doesn't know that it doesn't know. It's very inconvenient.
    - lmm 6y ago
      Why would adding a new custom mimetype and marking those files as using it be any easier than adding a new custom file extension and renaming those files to use it?