4 ms·

>Most extensions have three characters, which means the search space is pretty crowded. You may want to consider using four letters. Is there a reason not to u

>Most extensions have three characters, which means the search space is pretty crowded. You may want to consider using four letters. Is there a reason not to use a lot more characters? If your application's name is MustacheMingle, call the file foo.mustachemingle instead of foo.mumi? This will decrease the probability of collision to almost zero. I am unaware of any operating systems that don't allow it, and it will be 100% clear to the user which application the file belongs to. It will be less aesthetically pleasing than a shorter extension, but that's probably mainly a matter of habit. We're just not used to longer file name extensions. Any reason why this is a bad idea?

delusional 1y ago
> it will be 100% clear to the user which application the file belongs to. The most popular operating system hides it from the user, so clarity would not improve in that case. At leat one other (Linux) doesn't really use "extensions" and instead relies on magic headers inside the files to determine the format. Otherwise I think the decision is largely aestethic. If you value absolute clarity, then I don't see any reason it won't work, it'll just be a little "ugly"
- hiAndrewQuinn 1y ago
  I don't even think it's ugly. I'm incredibly thankful every time I see someone make e.g. `db.sqlite`, it immediately sets me at ease to know I'm not accidentally dealing with a DuckDB file or something.
  - wvbdmp 1y ago
    Yes, oh my god. Stop using .db for Sqlite files!!! It’s too generic and it’s already used by Windows for those thumbnail system files.
- dist-epoch 1y ago
  > At leat one other (Linux) doesn't really use "extensions" and instead relies on magic headers inside the files to determine the format. mostly for executable files. I doubt many Linux apps look inside a .py file to see if it's actually a JPEG they should build a thumbnail for.
  - scrollaway 1y ago
    Your doubts are incorrect. There's a fairly standard way of extracting the file type out of files on linux, which relies on a mix of extensions and magic bytes. Here's where you can start to read about this: https://wiki.archlinux.org/title/XDG_MIME_Applications https://wiki.archlinux.org/title/XDG_MIME_Applications A lot of apps implement this (including most file managers)
    - delusional 1y ago
      I'm a little surprised that that link doesn't go to libmagic[1]. No doubt XDG_MIME is an important spec for desktop file detection, but I think libmagic and the magic database that underpins it are more fundamental to filetype detection in general. It's also one of my favorite oddities on Linux. If you're a Windows user the idea of a database of signatures for filetypes that exists outside the application that "owns" a file type is novel and weird. [1]: https://man7.org/linux/man-pages/man3/libmagic.3.html https://man7.org/linux/man-pages/man3/libmagic.3.html
      - scrollaway 1y ago
        libmagic maintains its own separate database from xdg. XDG db is meant from the ground up to have other apps add to it etc… so that one is the one apps use as a library usually, if they want to integrate nicely and correctly with other installed apps. libmagic is the hacking of the two :)
- whyoh 1y ago
  >The most popular operating system hides it from the user, so clarity would not improve in that case. If you mean Windows, that's not entirely correct. It defaults to hiding only "known" file extensions, like txt, jpg and such. (Which IMO is even worse than hiding all of them; that would at least be consistent.) EDIT: Actually, I just checked and apparently an extension, even an exotic one, becomes "known" when it's associated with a program, so your point still stands.
Hackbraten 1y ago
A 14-character extension might cause UX issues in desktop environments and file managers, where screen real estate per directory entry is usually very limited. When under pixel pressure, a graphical file manager might choose to prioritize displaying the file extension and truncate only the base filename. This would help the user identify file formats. However, the longer the extension, the less space remains for the base name. So a low-entropy file extension with too many characters can contribute to poor UX.
dist-epoch 1y ago
> call the file foo.mustachemingle You could go the whole java way then foo.com.apache.mustachemingle > Any reason why this is a bad idea the focus should be on the name, not on the extension.
layer8 1y ago
It’s tedious to type when you want to do `ls *.mustachemingle` or similar. It’s prone to get cut off in UIs with dedicated columns for file extensions. As you say, it’s unconventional and therefore risks not being immediately recognized as a file extension. On the other hand, Java uses .properties as a file extension, so there is some precedent.
Rygian 1y ago
Why should a file format be locked down to one specific application?
- IAmBroom 1y ago
  Both species are needed: Generic, standardized formats like "jpg" and "pdf", and Application-specific formats like extension files or state files for your program, that you do not wish to share with competitors.
  - InsideOutSanta 1y ago
    I think the Mac got this right (before Mac OS X) and has since screwed it up. Every file had both a creator code and a type code. So, for every file, you would know which application created it and also which format it was. So, double-clicking the file opened it in the application it was made in, but the Mac would also know which other applications could open that file.

delusional 1y ago

> it will be 100% clear to the user which application the file belongs to. The most popular operating system hides it from the user, so clarity would not improve in that case. At leat one other (Linux) doesn't really use "extensions" and instead relies on magic headers inside the files to determine the format. Otherwise I think the decision is largely aestethic. If you value absolute clarity, then I don't see any reason it won't work, it'll just be a little "ugly"

hiAndrewQuinn 1y ago
I don't even think it's ugly. I'm incredibly thankful every time I see someone make e.g. `db.sqlite`, it immediately sets me at ease to know I'm not accidentally dealing with a DuckDB file or something.
- wvbdmp 1y ago
  Yes, oh my god. Stop using .db for Sqlite files!!! It’s too generic and it’s already used by Windows for those thumbnail system files.
dist-epoch 1y ago
> At leat one other (Linux) doesn't really use "extensions" and instead relies on magic headers inside the files to determine the format. mostly for executable files. I doubt many Linux apps look inside a .py file to see if it's actually a JPEG they should build a thumbnail for.
- scrollaway 1y ago
  Your doubts are incorrect. There's a fairly standard way of extracting the file type out of files on linux, which relies on a mix of extensions and magic bytes. Here's where you can start to read about this: https://wiki.archlinux.org/title/XDG_MIME_Applications https://wiki.archlinux.org/title/XDG_MIME_Applications A lot of apps implement this (including most file managers)
  - delusional 1y ago
    I'm a little surprised that that link doesn't go to libmagic[1]. No doubt XDG_MIME is an important spec for desktop file detection, but I think libmagic and the magic database that underpins it are more fundamental to filetype detection in general. It's also one of my favorite oddities on Linux. If you're a Windows user the idea of a database of signatures for filetypes that exists outside the application that "owns" a file type is novel and weird. [1]: https://man7.org/linux/man-pages/man3/libmagic.3.html https://man7.org/linux/man-pages/man3/libmagic.3.html
    - scrollaway 1y ago
      libmagic maintains its own separate database from xdg. XDG db is meant from the ground up to have other apps add to it etc… so that one is the one apps use as a library usually, if they want to integrate nicely and correctly with other installed apps. libmagic is the hacking of the two :)
whyoh 1y ago
>The most popular operating system hides it from the user, so clarity would not improve in that case. If you mean Windows, that's not entirely correct. It defaults to hiding only "known" file extensions, like txt, jpg and such. (Which IMO is even worse than hiding all of them; that would at least be consistent.) EDIT: Actually, I just checked and apparently an extension, even an exotic one, becomes "known" when it's associated with a program, so your point still stands.

Hackbraten 1y ago

A 14-character extension might cause UX issues in desktop environments and file managers, where screen real estate per directory entry is usually very limited. When under pixel pressure, a graphical file manager might choose to prioritize displaying the file extension and truncate only the base filename. This would help the user identify file formats. However, the longer the extension, the less space remains for the base name. So a low-entropy file extension with too many characters can contribute to poor UX.

dist-epoch 1y ago

> call the file foo.mustachemingle You could go the whole java way then foo.com.apache.mustachemingle > Any reason why this is a bad idea the focus should be on the name, not on the extension.

layer8 1y ago

It’s tedious to type when you want to do `ls *.mustachemingle` or similar. It’s prone to get cut off in UIs with dedicated columns for file extensions. As you say, it’s unconventional and therefore risks not being immediately recognized as a file extension. On the other hand, Java uses .properties as a file extension, so there is some precedent.

Rygian 1y ago

Why should a file format be locked down to one specific application?

IAmBroom 1y ago
Both species are needed: Generic, standardized formats like "jpg" and "pdf", and Application-specific formats like extension files or state files for your program, that you do not wish to share with competitors.
- InsideOutSanta 1y ago
  I think the Mac got this right (before Mac OS X) and has since screwed it up. Every file had both a creator code and a type code. So, for every file, you would know which application created it and also which format it was. So, double-clicking the file opened it in the application it was made in, but the Mac would also know which other applications could open that file.