Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The initial version of the /etc./magic file used by the file(1) command

retrocomputing.stackexchange.com

Post reply on HN
Print view View original

11–16 of 16 posts

Re: The initial version of the /etc./magic file used by the file(1) command

#11

Post by PhilipRoman »

jandrese wrote: post #3

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.

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

Re: The initial version of the /etc./magic file used by the file(1) command

#12

Post by jandrese »

PhilipRoman wrote: post #11
jandrese wrote: post #3

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.

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

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
You could also have a version FNRESGET that operates on file names instead of file descriptors. Also a setter. There's still obviously a lot of details to work out, but nothing about this should be all that difficult. It even simplifies some other parts of the system, for example if you have a network socket the socket metadata like the remote IP address and port numbers could be in the resource fork of the socket itself.

Re: The initial version of the /etc./magic file used by the file(1) command

#13

Post by genewitch »

kmeisthax wrote: post #10
genewitch wrote: post #9

Earlier quoted context omitted.

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 in…

I vouched because nothing you said seems incorrect on its face, and i don't know enough to incorrect you. Someone else could; rather than no discussion. It is good to know you no longer have to binhex mac stuff before zipping (and i assume tar, etc). That's why i sounded incredulous, even though the last time i used a mac the "install" was "drag this icon onto your hard drive icon"

I'm curious, if you have a disk/disc, and you drag a file onto the desktop, and eject the disk, does the file still disappear?

Re: The initial version of the /etc./magic file used by the file(1) command

#14

Post by genewitch »

kps wrote: post #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.

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"

Re: The initial version of the /etc./magic file used by the file(1) command

#15

Post by kps »

genewitch wrote: post #14
kps wrote: post #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.

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"

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

Re: The initial version of the /etc./magic file used by the file(1) command

#16

Post by genewitch »

kps wrote: post #15
genewitch wrote: post #14

Earlier quoted context omitted.

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"

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

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.
Post reply on HN