4 ms·

But even on system where they aren't needed they're useful IMO, for me as a user. Magic bytes mean you have to seek into each file, and if you care about file t

But even on system where they aren't needed they're useful IMO, for me as a user. Magic bytes mean you have to seek into each file, and if you care about file types, it means anything that lists files has to do that.

bayindirh 19d ago
Personally, I'm not against file extensions, and I like to see and use them, however when something (i.e. magic bytes of a file) is used a lot system-wide, the underlying mechanisms optimize towards the use case as a natural tendency. The interesting, or more accurately neat thing about EXT family of filesystems is, the file header is always one pointer away from your inode structure for that file. With NVMe disks or SSDs in general, this is a very cheap operation, even when done en-masse. Even when we were using HDDs, anti-fragmentation features of EXT3/4 kept that one seek pretty cheap. As a test, I fed my whole documents folder (~3500 files) into "file" tool to see what it does (via "file -f $filelist"). It finished in ~1,5 seconds. I redirected the output to /dev/null to eliminate the overhead incurred by printing things over SSH, though. While everything is fast for small n, the consideration of small for this operation goes a long way, AFAICS. Oracle has a great write-up about EXT4 and its structure: https://blogs.oracle.com/linux/understanding-ext4-disk-layout-part-1 https://blogs.oracle.com/linux/understanding-ext4-disk-layou...
- customguy 19d ago
  A cheap operation is still infinitely more costly than no operation at all though. And not everything is on a local SSD, even just with a NAS, not to mention FTP, I really wouldn't want there to be no file extensions. How would webdev look like? At first the HTML goes into "document", the style into "style", and before you know it, you're re-inventing extensions as prefixes or suffixes anyway, and I prefer users.sqlite to users_db. I honestly don't even see a problem to solve, so even the "cheapest" solution seems needlessly costly to me.
  - bayindirh 18d ago
    I don't see file extensions as a problem to be solved, either. My point is, it's nice that Linux (esp. Desktop Environment) ecosystem embraced magic byte parsing as a solution where having no extension creates problems. I'm just happy to have the option around, I don't want to deprecate or against file extensions. If you're interested, I can run some benchmarks on NFS and FTP as well, however.
NekkoDroid 18d ago
I personally am of the opinion that both make sense and should exist. Extensions are for a first pass filtering/displaying, while magic bytes should be the source of truth, which is extra important when parsing a file anyway. Linux's binfmt_misc[0] even supports matching on either. [0]: https://en.wikipedia.org/wiki/Binfmt_misc https://en.wikipedia.org/wiki/Binfmt_misc

bayindirh 19d ago

Personally, I'm not against file extensions, and I like to see and use them, however when something (i.e. magic bytes of a file) is used a lot system-wide, the underlying mechanisms optimize towards the use case as a natural tendency. The interesting, or more accurately neat thing about EXT family of filesystems is, the file header is always one pointer away from your inode structure for that file. With NVMe disks or SSDs in general, this is a very cheap operation, even when done en-masse. Even when we were using HDDs, anti-fragmentation features of EXT3/4 kept that one seek pretty cheap. As a test, I fed my whole documents folder (~3500 files) into "file" tool to see what it does (via "file -f $filelist"). It finished in ~1,5 seconds. I redirected the output to /dev/null to eliminate the overhead incurred by printing things over SSH, though. While everything is fast for small n, the consideration of small for this operation goes a long way, AFAICS. Oracle has a great write-up about EXT4 and its structure: https://blogs.oracle.com/linux/understanding-ext4-disk-layout-part-1 https://blogs.oracle.com/linux/understanding-ext4-disk-layou...

customguy 19d ago
A cheap operation is still infinitely more costly than no operation at all though. And not everything is on a local SSD, even just with a NAS, not to mention FTP, I really wouldn't want there to be no file extensions. How would webdev look like? At first the HTML goes into "document", the style into "style", and before you know it, you're re-inventing extensions as prefixes or suffixes anyway, and I prefer users.sqlite to users_db. I honestly don't even see a problem to solve, so even the "cheapest" solution seems needlessly costly to me.
- bayindirh 18d ago
  I don't see file extensions as a problem to be solved, either. My point is, it's nice that Linux (esp. Desktop Environment) ecosystem embraced magic byte parsing as a solution where having no extension creates problems. I'm just happy to have the option around, I don't want to deprecate or against file extensions. If you're interested, I can run some benchmarks on NFS and FTP as well, however.

NekkoDroid 18d ago

I personally am of the opinion that both make sense and should exist. Extensions are for a first pass filtering/displaying, while magic bytes should be the source of truth, which is extra important when parsing a file anyway. Linux's binfmt_misc[0] even supports matching on either. [0]: https://en.wikipedia.org/wiki/Binfmt_misc https://en.wikipedia.org/wiki/Binfmt_misc