Feature: Determining file types by headers in addition to extensions

[BenCheung0422]

What feature or improvement do you think would benefit Files?

I am not sure if this feature has already been proposed in other parts of the Internet, but I think this feature would be really good to be implemented natively in Files alone on the bare Windows OS. In this world, there can be file types with repeated extensions. One is .ts, either a MPEG transport stream file or a TypeScript scriping file. If the file type can be determined truly, the productivity and user experience can be strengthened if one has to handle file types with the same extension. A file type can usually be determined by file headers^1, like how Linux does[^2]. It can also benefit even for files without extensions, like README and LICENSE files, although by just the filenames, and still not something can be handled by Registry now[^3].

Windows only handles to determine file types by Registry and for further procedures like thumbnails (e.g. image previews), but the content is mostly not taken into consideration in the process. If it is something can be done with a filesystem explorer, it can be done more easily without having to think when Windows handles this thing, though I do not know whether they would, as I am not a Microsoft employee.

A database or a built-in handle can be implemented on Files originally. Perhaps can as well be done similarly of how file does.[^4] The first filter could just be also using extensions to filter out files that are not a part of the standard for a particular file type, like OGG would be usually suffixed by .ogg, .flac by standard but not .docx or something, which would be generally not expected to be treated the same. For the magic number test, both an online global database and offline local private database/customization can be done. Then, developers can submit the scripts or logics to the database as public file type (wording from the Windows documentation), but can also register only on local user computer as private file type. Notably that, it is not quite like the IANA MIME type database, which just states the documentations and standards. The app could sync the database entries from the online global database in addition to also handle private file types locally, and users can remove the local entry if it has already been implemented in the global database. Even though the file type detection can be more distinguishable, there can still be conflicting types in with smaller chances than just by extensions, but it could be another issue to be discussed with. However, it would take time and effort to build up a mature database, with aids of developers and engineering over the world and the digital world.

Other than the part of feature just determining the file type, more actions can be done like what is done by the Registry one. This includes file type description and file icons/thumbnails/previews, even actions. Obviously, these are useful only on the basis of file types, but not bare just file names or extension names. Thus, it would be further allowed to supply these customizations like they do with Registry after file type determination (though better, there can be conflicts as only one instance for some features could be activated or enabled at a time, like icons).

[^2]: Stack Exchange Ask Ubuntu: "Do file extensions have any purpose in Linux?" answered by Byte Commander [^3]: Stack Exchange Superuser: "How to set the default program for opening files without an extension in Windows?" answered by hasen [^4]: Stack Exchange UNIX & LINUX: "How are file types known if not from file suffix?" answered by chaos

Requirements

• File type determining feature in the app
• Online file type database
• Offline file type database

Files Version

3.7.11.0

Windows Version

10.0.26100.2033

Comments

Actually it somehow seems like to be a kind of big project instead of being a part of the Files software project. Of course it would be better if it is supported by the OS natively, but it is really different from how the feature worked by the Registry currently, thus unlikely to be handled by them.

Furthermore, now Windows does not support changing "default" behavior for file association by Registry^5, as on Windows 10/11 users cannot manage file association settings through such settings[^6], but instead seemingly just via Settings (user) and the mentioned interface^5 (app).

[^6]: Windows OS Hub: "Changing Default File Associations in Windows 10 and 11"; related Question thread on Microsoft Learn: "Registry Location For File Extension Associations"

[Lamparter]

Maybe developing a separate library for this would be good, and perhaps one day it might be used by Files. It's a very cool idea though.

[yaira2]

This is an interesting proposal! I'm curious if there's already a library available for this. My initial concern is that unless the information is available natively from Windows, performance can be a problem.