Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Determining file types by headers in addition to extensions #16368

Open
BenCheung0422 opened this issue Oct 19, 2024 · 2 comments
Open

Comments

@BenCheung0422
Copy link

BenCheung0422 commented Oct 19, 2024

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 headers1, like how Linux does2. 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 now3.

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).

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 Registry5, as on Windows 10/11 users cannot manage file association settings through such settings6, but instead seemingly just via Settings (user) and the mentioned interface5 (app).

Footnotes

  1. StackOverflow: "Is there a way to find file type?" answered by SilverWarior

  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

  5. StackOverflow: "Editing the Windows registry doesn't impact the default "open" action when double-clicking files" 2

  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
Copy link
Contributor

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
Copy link
Member

yaira2 commented Oct 27, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 🆕 New
Development

No branches or pull requests

3 participants