The initial version of the /etc./magic file used by the file(1) command
15 comments
·June 3, 2025kps
genewitch
I think this is probably a parsing error, if i read your comment correctly; like "git isn't 40 years old"; however the statement can be parsed as "the original commits and revision history are saved in its (now) git repository"
kps
It's really about the assumption that the past was like the present, only older. Unix didn't have version control when `file(1)` was written, unless you count last week's backup tapes. (Granted, ‘backup tapes with fancy labels’ is also the working model of git.)
genewitch
right, but if i take some vb6 thing i wrote and update it for .net or .ts or whatever, but i also upload the original vb6 project/file(s) into git as well, that satisfies the meaning of the sentence. we could probably think of a better way to say it as concisely, but, as i said, i just parsed it differently.
jandrese
I 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.
PhilipRoman
I think I would disagree on this one. While it would make some operations neater, I steer clear of any and all external file metadata for the simple reason that it is not portable (and never will be, because that would mean giving up the stream/pipe abstraction).
jandrese
It's not portable because nobody else adopted it. Had DOS and Unix also embraced the concept this would be a solved problem. Microsoft does actually have something on NTFS that works similarly, which is how Windows knows when something has been downloaded from the internet and warns you that it might be dangerous.
Having a standard to separate your data from your metadata isn't necessarily incompatible with streams. It would be something you would IOCTL on an open stream if you cared.
int fd;
fd = open("the_file", O_RDONLY);
if ( fd < 0 )
{
perror("the_file");
return -1;
}
char* filetype = NULL;
ioctl(fd, FDRESGET, "FILETYPE", &filetype);
if ( filetype != NULL )
{
printf("%s has a filetype of %s\n", "the_file", filetype);
}
rollcat
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)
frizlab
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.
timschmidt
I guess that makes https://justine.lol/ape.html and https://github.com/jart/cosmopolitan hacks on top of a hack.
genewitch
Yes those are the very epitome of hacks.
hedora
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.
genewitch
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.
kmeisthax
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.
> 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.