Why is a resource fork?
-
I'm not often driven to fits of rage over tech, but the last time I used an Apple was one of them. I'd like the OS designers over there to give me a good reason why they have their filesystem divided into "forks" and application files are distributed across different "forks" so you cannot find all the application files in one place. The fact that Apple would fork their filesystem such that every application has additional files on a different "resource" fork has got to be grounds for a severe beating at least. What is the possible upside of doing it this way? I want to be a fly on the wall in their design meetings. I bet they spend more time talking about what color of brushed aluminum their products should be than they do about stuff like the above.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I'm not often driven to fits of rage over tech, but the last time I used an Apple was one of them. I'd like the OS designers over there to give me a good reason why they have their filesystem divided into "forks" and application files are distributed across different "forks" so you cannot find all the application files in one place. The fact that Apple would fork their filesystem such that every application has additional files on a different "resource" fork has got to be grounds for a severe beating at least. What is the possible upside of doing it this way? I want to be a fly on the wall in their design meetings. I bet they spend more time talking about what color of brushed aluminum their products should be than they do about stuff like the above.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I'm not often driven to fits of rage over tech, but the last time I used an Apple was one of them. I'd like the OS designers over there to give me a good reason why they have their filesystem divided into "forks" and application files are distributed across different "forks" so you cannot find all the application files in one place. The fact that Apple would fork their filesystem such that every application has additional files on a different "resource" fork has got to be grounds for a severe beating at least. What is the possible upside of doing it this way? I want to be a fly on the wall in their design meetings. I bet they spend more time talking about what color of brushed aluminum their products should be than they do about stuff like the above.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Yeah, it's really forked. :) Sorry I didn't read Richards post before posting!
As the aircraft designer said, "Simplicate and add lightness". PartsBin an Electronics Part Organizer - Release Version 1.3.0 JaxCoder.com Latest Article: SimpleWizardUpdate
-
I'm not often driven to fits of rage over tech, but the last time I used an Apple was one of them. I'd like the OS designers over there to give me a good reason why they have their filesystem divided into "forks" and application files are distributed across different "forks" so you cannot find all the application files in one place. The fact that Apple would fork their filesystem such that every application has additional files on a different "resource" fork has got to be grounds for a severe beating at least. What is the possible upside of doing it this way? I want to be a fly on the wall in their design meetings. I bet they spend more time talking about what color of brushed aluminum their products should be than they do about stuff like the above.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
NTFS also has forks; it is called Alternate Data Streams. I never used apple forks, but suspect that there would be dozens of detail differences between them and NTFS. The main idea is the same, though: Provide a mechanism for keeping different kinds of data, relating to the same object/project/whatever separate but together. Like metadata and primary data. Movie and subtitles. Executable and debug information. ... There are a few common uses of ADS in NTFS. E.g. when you receive a file across the net, and ADS provides some information about its origin. Most people do not know, and do not care. If you copy the file to a FAT file system (e.g. 99.9% of all memory sticks), you loose that information anyway. Apple promoted its forks a lot. Microsoft not so; essentially they went for other alternatives (such as container file formats). I suspect that the main reason why they implemented it in NTFS was to kill the pro-Apple argument "They provide forks in the file system". If you want to look for forks in your NTFS file system, Sysinternals streams[^] is a useful tool to start with.
-
NTFS also has forks; it is called Alternate Data Streams. I never used apple forks, but suspect that there would be dozens of detail differences between them and NTFS. The main idea is the same, though: Provide a mechanism for keeping different kinds of data, relating to the same object/project/whatever separate but together. Like metadata and primary data. Movie and subtitles. Executable and debug information. ... There are a few common uses of ADS in NTFS. E.g. when you receive a file across the net, and ADS provides some information about its origin. Most people do not know, and do not care. If you copy the file to a FAT file system (e.g. 99.9% of all memory sticks), you loose that information anyway. Apple promoted its forks a lot. Microsoft not so; essentially they went for other alternatives (such as container file formats). I suspect that the main reason why they implemented it in NTFS was to kill the pro-Apple argument "They provide forks in the file system". If you want to look for forks in your NTFS file system, Sysinternals streams[^] is a useful tool to start with.
I'm aware of those in NTFS. The difference appears to be if for example, you copy your application from such a filesystem, to say fat32 and then use it from there, it won't break the app, because that information isn't critical to the app actually being functional. With apple? It seems like apps are all written to use that nonsense and won't work without it.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
NTFS also has forks; it is called Alternate Data Streams. I never used apple forks, but suspect that there would be dozens of detail differences between them and NTFS. The main idea is the same, though: Provide a mechanism for keeping different kinds of data, relating to the same object/project/whatever separate but together. Like metadata and primary data. Movie and subtitles. Executable and debug information. ... There are a few common uses of ADS in NTFS. E.g. when you receive a file across the net, and ADS provides some information about its origin. Most people do not know, and do not care. If you copy the file to a FAT file system (e.g. 99.9% of all memory sticks), you loose that information anyway. Apple promoted its forks a lot. Microsoft not so; essentially they went for other alternatives (such as container file formats). I suspect that the main reason why they implemented it in NTFS was to kill the pro-Apple argument "They provide forks in the file system". If you want to look for forks in your NTFS file system, Sysinternals streams[^] is a useful tool to start with.
trønderen wrote:
Indeed it is. Part of my nightly backup process on our build service is using
streamsto clean up build assets not under source control. I also delete all of those nasty little.DS_Storefolders left behind by Mac's. We have a couple people who insist on using Mac's X| and/or Linux to create data, even though we are a Microsoft house and build products exclusively for Windows.Software Zen:
delete this; -
I'm aware of those in NTFS. The difference appears to be if for example, you copy your application from such a filesystem, to say fat32 and then use it from there, it won't break the app, because that information isn't critical to the app actually being functional. With apple? It seems like apps are all written to use that nonsense and won't work without it.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Well, "nonsense"? It is a different way of organizing data. In a *nix environment, you'd rather be using two dozen tiny little files, sometimes spread all over the place. In my study days, it was claimed that in a typical Unix installation (this was pre-Linux), 80% of the files were smaller than 5K bytes, hence would fit in the 10 disk blocks (of 512 bytes each) directly referenced in the I-node, without needing an index page. (A great argument for why Unix should be chosen over the competitors!) I guess the average file size is somewhat higher today, but still *nix systems tend to have a huge number of small files that must all be present for an application to run, or say, for a build to succeed. One alternative is to use some container file format. A forked file is a super-simple container file! The problem (or advantage, seen from another point of view) is that most recent (that includes all formats developed this millennium, but not limited to that) container formats are so complex that it takes a good chunk of code to decode. If you do that, you presumably know what you are doing. If you really need to access the structures in an NTFS ADS "container" file, and you know how to access ADS, writing a tiny program to split the different streams into a directory with one "simple" file per stream. I would assume that it would be equally simple with a Mac forked file. If you don't care about the information in those other streams/forks, just ignore those files. You could have ignored the streams/forks in the original file as well! If you do care, but will not (/can not) use the original file system the simplest way is to unpack it to a directory. Almost all memory sticks are FAT. What happens when a Mac copies a forked file to a FAT memory stick? Does it loose information? Or does it include a wrapper that makes the set of forks appear as one single file? Or does it create a directory?
-
Well, "nonsense"? It is a different way of organizing data. In a *nix environment, you'd rather be using two dozen tiny little files, sometimes spread all over the place. In my study days, it was claimed that in a typical Unix installation (this was pre-Linux), 80% of the files were smaller than 5K bytes, hence would fit in the 10 disk blocks (of 512 bytes each) directly referenced in the I-node, without needing an index page. (A great argument for why Unix should be chosen over the competitors!) I guess the average file size is somewhat higher today, but still *nix systems tend to have a huge number of small files that must all be present for an application to run, or say, for a build to succeed. One alternative is to use some container file format. A forked file is a super-simple container file! The problem (or advantage, seen from another point of view) is that most recent (that includes all formats developed this millennium, but not limited to that) container formats are so complex that it takes a good chunk of code to decode. If you do that, you presumably know what you are doing. If you really need to access the structures in an NTFS ADS "container" file, and you know how to access ADS, writing a tiny program to split the different streams into a directory with one "simple" file per stream. I would assume that it would be equally simple with a Mac forked file. If you don't care about the information in those other streams/forks, just ignore those files. You could have ignored the streams/forks in the original file as well! If you do care, but will not (/can not) use the original file system the simplest way is to unpack it to a directory. Almost all memory sticks are FAT. What happens when a Mac copies a forked file to a FAT memory stick? Does it loose information? Or does it include a wrapper that makes the set of forks appear as one single file? Or does it create a directory?
Thanks for that short treatise on Unix file organization.:thumbsup:
The difficult we do right away... ...the impossible takes slightly longer.
-
I'm not often driven to fits of rage over tech, but the last time I used an Apple was one of them. I'd like the OS designers over there to give me a good reason why they have their filesystem divided into "forks" and application files are distributed across different "forks" so you cannot find all the application files in one place. The fact that Apple would fork their filesystem such that every application has additional files on a different "resource" fork has got to be grounds for a severe beating at least. What is the possible upside of doing it this way? I want to be a fly on the wall in their design meetings. I bet they spend more time talking about what color of brushed aluminum their products should be than they do about stuff like the above.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
honey the codewitch wrote:
I'm not often driven to fits of rage over tech, but the last time I used an Apple was one of them.
I've played with Apples a couple time throughout the numerous years. And by 'a couple' I mean not many more than 3 times. Long ago I remember trying to find their file system. Couldn't find it. It seemed every program kept control of its own place where it stored the user's files. I asked someone about it later, and they indicated I was correct - there was no way to get to that. It didn't seem to have the equivalent of Windows Explorer. I believe they since changed that. A few years ago I went to a Best Buy and saw a Mac. Figured I'd play again. Booted up Safari. They are touted as being 'intuitive.' No effin way. I tried everything I could to scroll down on the web page. I had never played with two-finger scroll on a mouse, so had no idea about it, and it didn't come to me. I placed the cursor at the right edge of the page. The scroll bar didn't automatically come up. I tried everything I could think of and couldn't get the damn web page to scroll down. At that point I figured they had clevered themselves all the way back into stupidity. I consider myself to be fairly technically proficient - learned enough on my own to be able to help other people fix their Window's problems. But I could not wrap my head around Apple's design decisions just by playing with their system. Does that make me an old dog that cannot be taught new tricks? I don't know. I understand their 'two-finger scroll' now that someone showed it to me, so I doubt it.
Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver
-
I'm not often driven to fits of rage over tech, but the last time I used an Apple was one of them. I'd like the OS designers over there to give me a good reason why they have their filesystem divided into "forks" and application files are distributed across different "forks" so you cannot find all the application files in one place. The fact that Apple would fork their filesystem such that every application has additional files on a different "resource" fork has got to be grounds for a severe beating at least. What is the possible upside of doing it this way? I want to be a fly on the wall in their design meetings. I bet they spend more time talking about what color of brushed aluminum their products should be than they do about stuff like the above.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I'm not often driven to fits of rage over tech, but the last time I used an Apple was one of them. I'd like the OS designers over there to give me a good reason why they have their filesystem divided into "forks" and application files are distributed across different "forks" so you cannot find all the application files in one place. The fact that Apple would fork their filesystem such that every application has additional files on a different "resource" fork has got to be grounds for a severe beating at least. What is the possible upside of doing it this way? I want to be a fly on the wall in their design meetings. I bet they spend more time talking about what color of brushed aluminum their products should be than they do about stuff like the above.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
If you mean what I think you mean, 'fork' isn't really the right term. Not sure what they call it TBH, but it's basically two separate filesystems made to look like one, but on a per-directory basis, if that makes any sense. So, for example, `/Applications` isn't just a single folder. It's two, and one of those is on a read-only file system. And that's why they've done it - it's a security feature. The read-only file system is immutable and contains all the built-in apps (for better or worse). Apps you install yourself go to the mutable one. It's also digitally signed, so if anyone _does_ manage to break in then your system won't boot. Hell yeah, secure or what? I mean, what then? A trip to dear old Apple I guess, bring your card.
Paul Sanders. If I had more time, I would have written a shorter letter - Blaise Pascal. Some of my best work is in the undo buffer.
-
If you mean what I think you mean, 'fork' isn't really the right term. Not sure what they call it TBH, but it's basically two separate filesystems made to look like one, but on a per-directory basis, if that makes any sense. So, for example, `/Applications` isn't just a single folder. It's two, and one of those is on a read-only file system. And that's why they've done it - it's a security feature. The read-only file system is immutable and contains all the built-in apps (for better or worse). Apps you install yourself go to the mutable one. It's also digitally signed, so if anyone _does_ manage to break in then your system won't boot. Hell yeah, secure or what? I mean, what then? A trip to dear old Apple I guess, bring your card.
Paul Sanders. If I had more time, I would have written a shorter letter - Blaise Pascal. Some of my best work is in the undo buffer.
The call them forks. The resource fork is the split off FS. I don't remember what they call the main fork.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
The call them forks. The resource fork is the split off FS. I don't remember what they call the main fork.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Do they? OK, it's just that, being a grumpy old git, I remember the days when a (resource) fork was something else entirely. Guess we're running out of terms, gotta recycle some of the old ones. I have to say, it _does_ make sense. Anyway, did I answer your question?
Paul Sanders. If I had more time, I would have written a shorter letter - Blaise Pascal. Some of my best work is in the undo buffer.
-
Do they? OK, it's just that, being a grumpy old git, I remember the days when a (resource) fork was something else entirely. Guess we're running out of terms, gotta recycle some of the old ones. I have to say, it _does_ make sense. Anyway, did I answer your question?
Paul Sanders. If I had more time, I would have written a shorter letter - Blaise Pascal. Some of my best work is in the undo buffer.
It's entirely possible I'm remembering incorrectly, but I could swear that's what it's called. Well, as far as your answer, you didn't tell me much I didn't already know. The issue is that that resource data doesn't always get copied properly.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
honey the codewitch wrote:
I'm not often driven to fits of rage over tech, but the last time I used an Apple was one of them.
I've played with Apples a couple time throughout the numerous years. And by 'a couple' I mean not many more than 3 times. Long ago I remember trying to find their file system. Couldn't find it. It seemed every program kept control of its own place where it stored the user's files. I asked someone about it later, and they indicated I was correct - there was no way to get to that. It didn't seem to have the equivalent of Windows Explorer. I believe they since changed that. A few years ago I went to a Best Buy and saw a Mac. Figured I'd play again. Booted up Safari. They are touted as being 'intuitive.' No effin way. I tried everything I could to scroll down on the web page. I had never played with two-finger scroll on a mouse, so had no idea about it, and it didn't come to me. I placed the cursor at the right edge of the page. The scroll bar didn't automatically come up. I tried everything I could think of and couldn't get the damn web page to scroll down. At that point I figured they had clevered themselves all the way back into stupidity. I consider myself to be fairly technically proficient - learned enough on my own to be able to help other people fix their Window's problems. But I could not wrap my head around Apple's design decisions just by playing with their system. Does that make me an old dog that cannot be taught new tricks? I don't know. I understand their 'two-finger scroll' now that someone showed it to me, so I doubt it.
Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver
The haven’t “changed” that because it was never true. The Mac’s equivalent to Windows Explorer is a process called Finder and it has been the central part of the Mac operating experience since 1984. Unless you were in some sort of kiosk mode you shouldn’t have needed to do anything to find it.
-
I'm not often driven to fits of rage over tech, but the last time I used an Apple was one of them. I'd like the OS designers over there to give me a good reason why they have their filesystem divided into "forks" and application files are distributed across different "forks" so you cannot find all the application files in one place. The fact that Apple would fork their filesystem such that every application has additional files on a different "resource" fork has got to be grounds for a severe beating at least. What is the possible upside of doing it this way? I want to be a fly on the wall in their design meetings. I bet they spend more time talking about what color of brushed aluminum their products should be than they do about stuff like the above.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Going to start off with one correction: Modern applications are not typically split across multiple forks and haven’t been for literally decades. I’m genuinely surprised you’re running into such applications at all in 2023. I’m also curious what tool you were using to manipulate the files that was breaking them, because Macs have always just transparently handled them. The original Mac file system supported two separate chunks of data per file system entry. There was a data fork which was an unstructured store mostly analogous to the single data stream most early file systems had, and a resource fork that held discrete chunks of data tagged with a type and an integer identifier. The resource fork served the dual purpose of simplifying the use of structured data and providing a means to help mitigate the extremely constrained systems of the day. Applications, for example, kept executable code in the resource fork in multiple chunks that could be loaded and unloaded at need (transparently to the coder) to fit within available memory, not unlike overlay files on MS-DOS. But Mac applications haven’t typically been structured that was since the release of Mac OS X. So again, the fact that you’re running into them in 2023 is somewhat baffling.
-
It's entirely possible I'm remembering incorrectly, but I could swear that's what it's called. Well, as far as your answer, you didn't tell me much I didn't already know. The issue is that that resource data doesn't always get copied properly.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
OK. FWIW, (and for anyone else who might be interested) there's a better explanation of this read only filesystem business here: [https://superuser.com/a/1495146/546261\](https://superuser.com/a/1495146/546261) > The issue is that that resource data doesn't always get copied properly. Don't understand that (but would like to help). Do you mean [the contents of] an app's `Resources` folder? And from where to where (in terms of volumes)? If you're trying to stuff things into `/Applications`, that's what the Installer app is for. That's what I do (I build an installer package, using `pkgbuild` and then `productbuild`) and everything works fine. Or am I trying to teach my grandmother to suck eggs?
Paul Sanders. If I had more time, I would have written a shorter letter - Blaise Pascal. Some of my best work is in the undo buffer.
-
NTFS also has forks; it is called Alternate Data Streams. I never used apple forks, but suspect that there would be dozens of detail differences between them and NTFS. The main idea is the same, though: Provide a mechanism for keeping different kinds of data, relating to the same object/project/whatever separate but together. Like metadata and primary data. Movie and subtitles. Executable and debug information. ... There are a few common uses of ADS in NTFS. E.g. when you receive a file across the net, and ADS provides some information about its origin. Most people do not know, and do not care. If you copy the file to a FAT file system (e.g. 99.9% of all memory sticks), you loose that information anyway. Apple promoted its forks a lot. Microsoft not so; essentially they went for other alternatives (such as container file formats). I suspect that the main reason why they implemented it in NTFS was to kill the pro-Apple argument "They provide forks in the file system". If you want to look for forks in your NTFS file system, Sysinternals streams[^] is a useful tool to start with.
Yep. I tried using Alternate Data Streams to hide some copyright info, but source control (SVN at the time, and SourceSafe) wouldn’t pick it up. I read that malware was oftentimes stored in there. :thumbsup:
Time is the differentiation of eternity devised by man to measure the passage of human events. - Manly P. Hall Mark Just another cog in the wheel
-
Yep. I tried using Alternate Data Streams to hide some copyright info, but source control (SVN at the time, and SourceSafe) wouldn’t pick it up. I read that malware was oftentimes stored in there. :thumbsup:
Time is the differentiation of eternity devised by man to measure the passage of human events. - Manly P. Hall Mark Just another cog in the wheel
Also, this is close relative of 'Security through obscurity'. Anyone who is aware of your copyright notice mechanism can remove it by copying your file to a memory stick and back. So why would your copyright notice have any value at all, if it might very easily disappear, and you can't tell people about its existence because that would make it trivial to remove it? So I think you were right dropping this alternative. Yet I think a source control system should be able to handle all sorts of files, including those with ADS, holes, file names with spaces and extended character sets, or whatever. To phrase it differently: Anything with roots in *nix is likely to give you problems for at least the first ten years after it was "ported" (or "tried ported" might be a more appropriate term) to a Windows environment.
-
OK. FWIW, (and for anyone else who might be interested) there's a better explanation of this read only filesystem business here: [https://superuser.com/a/1495146/546261\](https://superuser.com/a/1495146/546261) > The issue is that that resource data doesn't always get copied properly. Don't understand that (but would like to help). Do you mean [the contents of] an app's `Resources` folder? And from where to where (in terms of volumes)? If you're trying to stuff things into `/Applications`, that's what the Installer app is for. That's what I do (I build an installer package, using `pkgbuild` and then `productbuild`) and everything works fine. Or am I trying to teach my grandmother to suck eggs?
Paul Sanders. If I had more time, I would have written a shorter letter - Blaise Pascal. Some of my best work is in the undo buffer.
[Edit: I replied to the wrong post]
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
