The initial version of the /etc./magic file used by the file(1) command
retrocomputing.stackexchange.com
The initial version of the /etc./magic file used by the file(1) command
1–10 of 16 posts
Re: The initial version of the /etc./magic file used by the file(1) command
#2> Today, we can go all the way back to its first commit from around 40 years ago via its Git repository
I can't wait to see someone to find the first commit of SCCS via its Git repository.
Re: The initial version of the /etc./magic file used by the file(1) command
#3I still think it is a shame that Unix never adopted the concept of the resource fork from Macs. Having a pair of 4 byte fields that denote file type and associated program is so much better than reading the first few bytes of the data and guessing. file(1) is and has always been a hack.
Re: The initial version of the /etc./magic file used by the file(1) command
#4I still think it is a shame that Unix never adopted the concept of the resource fork from Macs. Having a pair of 4 byte fields that denote file type and associated program is so much better than reading the first few bytes of the data and guessing. file(1) is and has always been a hack.
Today we still have xattrs, but it's not even too late, it's simply impossible; even OS X gave up on resource forks, because PCs won.
(An excerpt from history.txt)
Re: The initial version of the /etc./magic file used by the file(1) command
#5I still think it is a shame that Unix never adopted the concept of the resource fork from Macs. Having a pair of 4 byte fields that denote file type and associated program is so much better than reading the first few bytes of the data and guessing. file(1) is and has always been a hack.
Today we still have xattrs, but it's not even too late, it's simply impossible; even OS X gave up on resource forks, because PCs won. (An excerpt from history.txt)
macOS has xattrs too (had them very early actually), and supports resource forks through them (it’s the same concept), though they are not used anymore except in some fringe cases.
Re: The initial version of the /etc./magic file used by the file(1) command
#6I still think it is a shame that Unix never adopted the concept of the resource fork from Macs. Having a pair of 4 byte fields that denote file type and associated program is so much better than reading the first few bytes of the data and guessing. file(1) is and has always been a hack.
I’ve repeatedly lost data copying files off macs (especially pre-osx) because some things move the file header into the resource fork, and other things ignore the resource fork when copying to other operating systems.
Re: The initial version of the /etc./magic file used by the file(1) command
#7I still think it is a shame that Unix never adopted the concept of the resource fork from Macs. Having a pair of 4 byte fields that denote file type and associated program is so much better than reading the first few bytes of the data and guessing. file(1) is and has always been a hack.
I guess that makes https://justine.lol/ape.html and https://github.com/jart/cosmopolitan hacks on top of a hack.
Re: The initial version of the /etc./magic file used by the file(1) command
#8I still think it is a shame that Unix never adopted the concept of the resource fork from Macs. Having a pair of 4 byte fields that denote file type and associated program is so much better than reading the first few bytes of the data and guessing. file(1) is and has always been a hack.
I guess that makes https://justine.lol/ape.html and https://github.com/jart/cosmopolitan hacks on top of a hack.
Yes those are the very epitome of hacks.
Re: The initial version of the /etc./magic file used by the file(1) command
#9I still think it is a shame that Unix never adopted the concept of the resource fork from Macs. Having a pair of 4 byte fields that denote file type and associated program is so much better than reading the first few bytes of the data and guessing. file(1) is and has always been a hack.
I’ve repeatedly lost data copying files off macs (especially pre-osx) because some things move the file header into the resource fork, and other things ignore the resource fork when copying to other operating systems.
Wait, macOS still doss this? So you still have to use stuffit for a platform agnostic transfer? Don't get me wrong, hacking everything with resedit and the like almost makes me reach for the rose glasses.
I have scads of macOS footprints all over my NAS from a Mac I used a decade ago.
Re: The initial version of the /etc./magic file used by the file(1) command
#10Earlier quoted context omitted.
I’ve repeatedly lost data copying files off macs (especially pre-osx) because some things move the file header into the resource fork, and other things ignore the resource fork when copying to other operating systems.
Wait, macOS still doss this? So you still have to use stuffit for a platform agnostic transfer? Don't get me wrong, hacking everything with resedit and the like almost makes me reach for the rose glasses. I have scads of macOS footprints all over my NAS from a Mac I used a decade ago.
Mac OS X (because NeXT) switched packaging format from resource forks to directory hives, which are just as alien a concept, but with the advantage that most tools that silently ignore the resource fork will work correctly on directories.
Stuffit is, AFAIK, dead. Along with all the various other OS9-era packaging formats for resource fork files. If you need to send a directory hive over something that only accepts individual files you send a disk image or ZIP archive, both of which macOS will happily extract for you.