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.
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 < 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);
}
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.
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.
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.
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?
> 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.)
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.
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.
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.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.
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.
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.
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?