Re: Resource Fork - is this a good use/the right thing to do?
Honestly, I don't care how the data is stored, as long as I've got some reliable place to store file-specific data such that it can be reliably tied to the file (cross-user/cross-computer concerns are primary, cross-platform concerns are secondary - I'm only writing this for OS X currently, and I could always have export and import functionality to keep a real file around while the target file gets sent out and about and then recombine them later). If that means writing raw binary or XML data to an unformatted resource fork, that's fine. If that means I've got to put it into a resource with it's own type, that's fine too (this would be a bit more reliable, I imagine, as it's possible I'll run into files with other things in their resource forks already). If that means something else entirely, that's cool too. Now, if y'all could explain what a resource map is (the docs don't show anything meaningful) and why I might be using it, it'd be appreciated. -Dan On Apr 24, 2008, at 12:52 AM, Graham Cox wrote: On 24 Apr 2008, at 2:46 pm, Chris Suter wrote: On 24/04/2008, at 2:28 PM, Graham Cox wrote: On 24 Apr 2008, at 12:59 pm, Chris Suter wrote: The limits for resource forks are the same as for data forks Not true - the ResourceMap contains some 24-bit pointers, or at least it used to, as well as some 16-bit length fields as well. Unless these have been changed (possible I guess, I don't know) these will bite you before the file fork limitations do. I'm sorry, but it is true. We're not talking about ResourceMaps, we're talking about resource forks. ResourceMaps are just one thing that you might store in a resource fork but I don't know of any reason why you can't store anything you like in them and the limits for a resource fork are the same as those for a data fork. - Chris Sure, the fork limitations are the same. But the OP was talking about storing data in the Resource Fork as a resource (correct me if I'm wrong, I've only been following the thread peripherally) so ResourceMaps do come into it. G. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Resource Fork - is this a good use/the right thing to do?
On 24/04/2008, at 4:14 PM, Daniel DeCovnick wrote: Honestly, I don't care how the data is stored, as long as I've got some reliable place to store file-specific data such that it can be reliably tied to the file (cross-user/cross-computer concerns are primary, cross-platform concerns are secondary - I'm only writing this for OS X currently, and I could always have export and import functionality to keep a real file around while the target file gets sent out and about and then recombine them later). If that means writing raw binary or XML data to an unformatted resource fork, that's fine. If that means I've got to put it into a resource with it's own type, that's fine too (this would be a bit more reliable, I imagine, as it's possible I'll run into files with other things in their resource forks already). If that means something else entirely, that's cool too. Now, if y'all could explain what a resource map is (the docs don't show anything meaningful) and why I might be using it, it'd be appreciated. You don't want to manipulate it directly. Use the API documented here: http://developer.apple.com/documentation/Carbon/Reference/Resource_Manager/Reference/reference.html - Chris smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Resource Fork - is this a good use/the right thing to do?
I read that. I'm not sure I completely know what the resource map is. The resource manager keeps track of a table of resource types, and subtables of resource names or ID's as the key in a key-value pair, where the resources themselves are the values. Is that what the map is, that whole data structure that the manager keeps track of? FWIW, as far as manipulating resource forks go, I was planning to use the NDResourceFork classes (see further up this thread about 20 posts). If what that does is the wrong way to go (I suspect it's not), let me know. And, if I'm wrong about what the map is, if by using NDResourceFork I don't need to concern myself with what a resource map actually is so long as I make sure I stick to my own crazy 4-char resource type (say, dåNd, or s¥$w) and valid resource ID ranges, let me know that also. :-) And if I do have a substantial part of that right, what are the limits I need to worry about? Uli mentioned a limit of 2727 resources per fork. While that seems absurdly low, it's not like I'd be using a resource for every piece of data I need to keep track of. Far simpler just to serialize my data and write it to a single resource if that sort of limit exists; shove my XML or binary data into blah.blahresource forks¥$w128. I know that a single resource can be at least 3 MB*. What's the limit there, for instance? -Dan *How do I know? Funny story, but the moral is I ended up writing I will not paste 3 images into ResEdit PICT resources and then email the plugin to someone on dialup 50 times in penance using a SimpleText copy with the Paste menu item removed. On Apr 24, 2008, at 2:27 AM, Chris Suter wrote: On 24/04/2008, at 4:14 PM, Daniel DeCovnick wrote: Honestly, I don't care how the data is stored, as long as I've got some reliable place to store file-specific data such that it can be reliably tied to the file (cross-user/cross-computer concerns are primary, cross-platform concerns are secondary - I'm only writing this for OS X currently, and I could always have export and import functionality to keep a real file around while the target file gets sent out and about and then recombine them later). If that means writing raw binary or XML data to an unformatted resource fork, that's fine. If that means I've got to put it into a resource with it's own type, that's fine too (this would be a bit more reliable, I imagine, as it's possible I'll run into files with other things in their resource forks already). If that means something else entirely, that's cool too. Now, if y'all could explain what a resource map is (the docs don't show anything meaningful) and why I might be using it, it'd be appreciated. You don't want to manipulate it directly. Use the API documented here: http://developer.apple.com/documentation/Carbon/Reference/Resource_Manager/Reference/reference.html - Chris ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Resource Fork - is this a good use/the right thing to do?
Am 24.04.2008 um 09:16 schrieb Daniel DeCovnick: I read that. I'm not sure I completely know what the resource map is. The resource manager keeps track of a table of resource types, and subtables of resource names or ID's as the key in a key-value pair, where the resources themselves are the values. Is that what the map is, that whole data structure that the manager keeps track of? Yes. The resource map is the table of contents of a resource file. It uses offsets into the file to point from the type, ID number (and optional name) of a file to its actual contents. Since resources have been around pretty much since the days of the first Macintosh operating system, they use rather small number types for today's computers. FWIW, as far as manipulating resource forks go, I was planning to use the NDResourceFork classes (see further up this thread about 20 posts). If what that does is the wrong way to go (I suspect it's not), let me know. And, if I'm wrong about what the map is, if by using NDResourceFork I don't need to concern myself with what a resource map actually is so long as I make sure I stick to my own crazy 4-char resource type (say, dåNd, or s¥$w) and valid resource ID ranges, let me know that also. :-) Apple has documentation about what resource types are reserved for use by Apple. IIRC they must contain at least one uppercase character. I'd recommend you use the signature registry on Apple's web site to register a signature, and use that. That decreases chances of your type colliding with any in use. Though you'll still have to make sure it doesn't collide with a well-known resource type. Check out the Cocoa-Dev and Carbon-Dev archives, there was a thread on one of these lists whether signatures (creator codes) are still needed today, and we dug out the documentation about what resource types are reserved in the process. And if I do have a substantial part of that right, what are the limits I need to worry about? Uli mentioned a limit of 2727 resources per fork. While that seems absurdly low, it's not like I'd be using a resource for every piece of data I need to keep track of. It's a technical limit. That's the point at which one of its offsets overflows, IIRC. You need to be careful with that, as the resource manager will simply crash when you exceed that. Far simpler just to serialize my data and write it to a single resource if that sort of limit exists; shove my XML or binary data into blah.blahresource forks¥$w128. I know that a single resource can be at least 3 MB*. What's the limit there, for instance? I'll try if I can find a backup of my blog posting on the topic. I don't have the nerve to go back to Inside Macintosh: More Macintosh Toolbox to re-read the documentation of the resource file format. However, if anyone else wants to, the format is documented here: http://developer.apple.com/documentation/mac/MoreToolbox/MoreToolbox-99.html#HEADING99-0 One of the limits that immediately comes to mind is that the beginning of the resource map has to be within 64k bytes from both the resource type list and the name list, which puts a hard limit on the size of the resource map (see Fig. 1-14). Similar limits seem to be on the name list and a few other lists. Note that the 2727 limit is a well- known bug, so to say, I don't think Apple has documented it anywhere. Cheers, -- Uli Kusterer The Witnesses of TeachText are everywhere... http://www.zathras.de ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Resource Fork - is this a good use/the right thing to do?
Am 24.04.2008 um 06:28 schrieb Graham Cox: On 24 Apr 2008, at 12:59 pm, Chris Suter wrote: The limits for resource forks are the same as for data forks Not true - the ResourceMap contains some 24-bit pointers, or at least it used to, as well as some 16-bit length fields as well. Unless these have been changed (possible I guess, I don't know) these will bite you before the file fork limitations do. I was imprecise in my original statement. I meant what Graham says: The resource FILE format has some limits (offsets and things it uses are 24- and 16-bit quantities, as Graham said. Of course, the resource FORK itself can grow as much as it wants. But that won't help you much, since applications like the Finder expect the resource FORK to contain a valid resource FILE so they can add their own 'usro' resources and such that indicate what app to open a file with. So, for all practical purposes resource FORKS are limited by the format of the resource FILE. Cheers, -- Uli Kusterer The Witnesses of TeachText are everywhere... http://www.zathras.de ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Resource Fork - is this a good use/the right thing to do?
The tips are appreciated. AFAICT, the limit on total resource sizes is within a kB or 2 of 2 or 4 GB, with the limitation that the last resource must start within the first ~16 MB. Given the fact that the files I'm opening are in the 1-300k range, I suspect I have bigger problems than the resource file format if I start to approach that limit. One thing I can't figure out though... why is the limit 2727? Assuming you have only 1 resource type and no names, you can fit exactly twice that many references in the map. It's not relevant to my problem, but I am curious. -Dan On Apr 24, 2008, at 5:52 AM, Uli Kusterer wrote: Am 24.04.2008 um 09:16 schrieb Daniel DeCovnick: I read that. I'm not sure I completely know what the resource map is. The resource manager keeps track of a table of resource types, and subtables of resource names or ID's as the key in a key-value pair, where the resources themselves are the values. Is that what the map is, that whole data structure that the manager keeps track of? Yes. The resource map is the table of contents of a resource file. It uses offsets into the file to point from the type, ID number (and optional name) of a file to its actual contents. Since resources have been around pretty much since the days of the first Macintosh operating system, they use rather small number types for today's computers. FWIW, as far as manipulating resource forks go, I was planning to use the NDResourceFork classes (see further up this thread about 20 posts). If what that does is the wrong way to go (I suspect it's not), let me know. And, if I'm wrong about what the map is, if by using NDResourceFork I don't need to concern myself with what a resource map actually is so long as I make sure I stick to my own crazy 4-char resource type (say, dåNd, or s¥$w) and valid resource ID ranges, let me know that also. :-) Apple has documentation about what resource types are reserved for use by Apple. IIRC they must contain at least one uppercase character. I'd recommend you use the signature registry on Apple's web site to register a signature, and use that. That decreases chances of your type colliding with any in use. Though you'll still have to make sure it doesn't collide with a well-known resource type. Check out the Cocoa-Dev and Carbon-Dev archives, there was a thread on one of these lists whether signatures (creator codes) are still needed today, and we dug out the documentation about what resource types are reserved in the process. And if I do have a substantial part of that right, what are the limits I need to worry about? Uli mentioned a limit of 2727 resources per fork. While that seems absurdly low, it's not like I'd be using a resource for every piece of data I need to keep track of. It's a technical limit. That's the point at which one of its offsets overflows, IIRC. You need to be careful with that, as the resource manager will simply crash when you exceed that. Far simpler just to serialize my data and write it to a single resource if that sort of limit exists; shove my XML or binary data into blah.blahresource forks¥$w128. I know that a single resource can be at least 3 MB*. What's the limit there, for instance? I'll try if I can find a backup of my blog posting on the topic. I don't have the nerve to go back to Inside Macintosh: More Macintosh Toolbox to re-read the documentation of the resource file format. However, if anyone else wants to, the format is documented here: http://developer.apple.com/documentation/mac/MoreToolbox/MoreToolbox-99.html#HEADING99-0 One of the limits that immediately comes to mind is that the beginning of the resource map has to be within 64k bytes from both the resource type list and the name list, which puts a hard limit on the size of the resource map (see Fig. 1-14). Similar limits seem to be on the name list and a few other lists. Note that the 2727 limit is a well-known bug, so to say, I don't think Apple has documented it anywhere. Cheers, -- Uli Kusterer The Witnesses of TeachText are everywhere... http://www.zathras.de ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Resource Fork - is this a good use/the right thing to do?
On Thu, Apr 24, 2008 at 12:46 AM, Chris Suter [EMAIL PROTECTED] wrote: On 24/04/2008, at 2:28 PM, Graham Cox wrote: On 24 Apr 2008, at 12:59 pm, Chris Suter wrote: The limits for resource forks are the same as for data forks Not true - the ResourceMap contains some 24-bit pointers, or at least it used to, as well as some 16-bit length fields as well. Unless these have been changed (possible I guess, I don't know) these will bite you before the file fork limitations do. I'm sorry, but it is true. We're not talking about ResourceMaps, we're talking about resource forks. ResourceMaps are just one thing that you might store in a resource fork but I don't know of any reason why you can't store anything you like in them and the limits for a resource fork are the same as those for a data fork. It's technically true that you can put arbitrary data in the resource fork, but it's also a bad idea. Various software such as the Finder will write to the resource forks of arbitrary files and in doing so will assume that either the resource fork doesn't exist or is in the standard resource format. If you store data in a different format then this software will either corrupt it or disable these features. Either way the user is left holding the bag. Mike ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Resource Fork - is this a good use/the right thing to do?
On Apr 24, 2008, at 6:08 AM, Daniel DeCovnick wrote: The tips are appreciated. AFAICT, the limit on total resource sizes is within a kB or 2 of 2 or 4 GB, with the limitation that the last resource must start within the first ~16 MB. Given the fact that the files I'm opening are in the 1-300k range, I suspect I have bigger problems than the resource file format if I start to approach that limit. One thing I can't figure out though... why is the limit 2727? Assuming you have only 1 resource type and no names, you can fit exactly twice that many references in the map. It's not relevant to my problem, but I am curious. Each resource entry is a 12 byte structure (2 byte ID, 2 byte offset to name, 1 byte flag, 3 byte offset to data, 4 bytes used as handle when loaded into memory). Combined with 2 byte offset limit on the size of the resource entry list, that gives 65535 / 12 = 2727. Glenn Andreas [EMAIL PROTECTED] http://www.gandreas.com/ wicked fun! Cardographer | the custom playing card designer ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Resource Fork - is this a good use/the right thing to do?
On Thu, Apr 24, 2008 at 4:28 PM, Daniel DeCovnick [EMAIL PROTECTED] wrote: Er... either my calculator's broken or (65535 - 30 - 8 )/12 = 5458, not 2727, where 30 and 8 are the resource map header and a single reference type. However, floor((32767 - 30 - 8) / 12) = 2727. Maybe the use of a signed int is the well-known bug Uli referred to. Hamish ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Resource Fork - is this a good use/the right thing to do?
On Thu, Apr 24, 2008 at 4:28 PM, Hamish Allan wrote: Maybe the use of a signed int is the well-known bug Uli referred to. Indeed it is. Tech Note TB18 (1988) http://beta.devworld.apple.com/technotes/tb/tb_18.html ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Resource Fork - is this a good use/the right thing to do?
On 22 Apr '08, at 10:21 PM, Daniel DeCovnick wrote: Through a lot of thought experiments, I've come to the conclusion that the best place to save this sort of thing would be in the resource fork of the file being opened, but I could be totally off the mark there, and it's certainly an unorthodox thing to do. It would have been the right thing to do ten years ago. But these days resource forks are definitely a legacy feature and it would be a bad idea to write new software that relies on them. Have you looked at Extended Attributes? They're kind of the moral equivalent of resources, but they're newer, lighter-weight and better integrated into the filesystem. I don't know if there's any in-depth documentation, but you can start by reading the man pages for getxattr, setxattr, et al. Option 3. Add my own Metadata key and put an XML or similarly textual version of my graphical rep as the string. I have no idea whether or not this is possible. It seems like a bad abuse of the metadata system in any case. This seems reasonable. It's the same way that the Finder stores comments, which is analogous to what you're doing. Option 4. Wrap the file anyway and put an alias where it used to be. Seems like a bad idea. Yes, the target user base for this app would know what was going on, but it just seems wrong to hide people's stuff like that. Way too much software doesn't understand/resolve alias files, so this could cause trouble. A symlink would be more transparent, but I agree with you that messing with the location of people's files is a bad idea. —Jens smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Resource Fork - is this a good use/the right thing to do?
On Apr 23, 2008, at 2:07 AM, Jens Alfke wrote: On 22 Apr '08, at 10:21 PM, Daniel DeCovnick wrote: Through a lot of thought experiments, I've come to the conclusion that the best place to save this sort of thing would be in the resource fork of the file being opened, but I could be totally off the mark there, and it's certainly an unorthodox thing to do. It would have been the right thing to do ten years ago. But these days resource forks are definitely a legacy feature and it would be a bad idea to write new software that relies on them. Have you looked at Extended Attributes? They're kind of the moral equivalent of resources, but they're newer, lighter-weight and better integrated into the filesystem. I don't know if there's any in-depth documentation, but you can start by reading the man pages for getxattr, setxattr, et al. Thanks for the suggestion. I've just looked through them now, as well as at the OSXBook (Mac OS X Internals: A Systems Approach by Amit Singh) info on that. In theory it looks good, but it's somewhat confusing. It looks like, at least in 10.4, except for the resource fork which is mapped as a fake xattr, you can only have inline attributes, with a length limit of 3802 bytes, and it would be quite common for my data to be significantly larger than that. Does anyone know if that's changed for 10.5? Option 3. Add my own Metadata key and put an XML or similarly textual version of my graphical rep as the string. I have no idea whether or not this is possible. It seems like a bad abuse of the metadata system in any case. This seems reasonable. It's the same way that the Finder stores comments, which is analogous to what you're doing. I dunno... it just seems that there's nowhere that the metadata system isn't integrated with Spotlight, and here, it wouldn't be. Seems to violate the spirit a bit. Still, it probably meets all the requirements. Thanks for the suggestions, Dan ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Resource Fork - is this a good use/the right thing to do?
On 23/04/2008, at 5:41 PM, Daniel DeCovnick wrote: Thanks for the suggestion. I've just looked through them now, as well as at the OSXBook (Mac OS X Internals: A Systems Approach by Amit Singh) info on that. In theory it looks good, but it's somewhat confusing. It looks like, at least in 10.4, except for the resource fork which is mapped as a fake xattr, you can only have inline attributes, with a length limit of 3802 bytes, and it would be quite common for my data to be significantly larger than that. Does anyone know if that's changed for 10.5? As an alternative to storing the information with the file itself, could your application store an alias record to the file along with your custom data in a data store managed by your application? That way you don't need to modify the original files in any way. You can use BDAlias or one of the other Obj-C wrappers for the alias management code. -- Rob Keniger ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Resource Fork - is this a good use/the right thing to do?
On 23/04/2008, at 5:41 PM, Daniel DeCovnick wrote: Thanks for the suggestion. I've just looked through them now, as well as at the OSXBook (Mac OS X Internals: A Systems Approach by Amit Singh) info on that. In theory it looks good, but it's somewhat confusing. It looks like, at least in 10.4, except for the resource fork which is mapped as a fake xattr, you can only have inline attributes, with a length limit of 3802 bytes, and it would be quite common for my data to be significantly larger than that. Does anyone know if that's changed for 10.5? I say, if using the resource fork works for you, go for it. Whatever disadvantages there might be are 1) theoretical, and 2) no worse than extended attributes. No sense bending over backward to try to get some supposedly superior solution to work not quite as well as the resource fork would. That's my two cents, anyway. Cheers, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Resource Fork - is this a good use/the right thing to do?
I'd second that. The OS (well, Finder) also adds things to the resource fork of files (custom icons, info about which app to open a file with when you changed it from the default etc). Just as long as you respect the existing contents this is exactly where you should put your data. On 23 Apr 2008, at 14:29, Ken Thomases wrote: On 23/04/2008, at 5:41 PM, Daniel DeCovnick wrote: Thanks for the suggestion. I've just looked through them now, as well as at the OSXBook (Mac OS X Internals: A Systems Approach by Amit Singh) info on that. In theory it looks good, but it's somewhat confusing. It looks like, at least in 10.4, except for the resource fork which is mapped as a fake xattr, you can only have inline attributes, with a length limit of 3802 bytes, and it would be quite common for my data to be significantly larger than that. Does anyone know if that's changed for 10.5? I say, if using the resource fork works for you, go for it. Whatever disadvantages there might be are 1) theoretical, and 2) no worse than extended attributes. No sense bending over backward to try to get some supposedly superior solution to work not quite as well as the resource fork would. That's my two cents, anyway. Cheers, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/matt.gough%40agfa.com This email sent to [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Resource Fork - is this a good use/the right thing to do?
On Apr 23, 2008, at 12:41 AM, Daniel DeCovnick wrote: On Apr 23, 2008, at 2:07 AM, Jens Alfke wrote: On 22 Apr '08, at 10:21 PM, Daniel DeCovnick wrote: Through a lot of thought experiments, I've come to the conclusion that the best place to save this sort of thing would be in the resource fork of the file being opened, but I could be totally off the mark there, and it's certainly an unorthodox thing to do. It would have been the right thing to do ten years ago. But these days resource forks are definitely a legacy feature and it would be a bad idea to write new software that relies on them. Have you looked at Extended Attributes? They're kind of the moral equivalent of resources, but they're newer, lighter-weight and better integrated into the filesystem. I don't know if there's any in-depth documentation, but you can start by reading the man pages for getxattr, setxattr, et al. Thanks for the suggestion. I've just looked through them now, as well as at the OSXBook (Mac OS X Internals: A Systems Approach by Amit Singh) info on that. In theory it looks good, but it's somewhat confusing. It looks like, at least in 10.4, except for the resource fork which is mapped as a fake xattr, you can only have inline attributes, with a length limit of 3802 bytes, and it would be quite common for my data to be significantly larger than that. Does anyone know if that's changed for 10.5? The limits aren't very well documented (or implemented), but you can avoid the limit by splitting it into multiple attributes. We save notes as extended attributes in Skim; this link is to a BSD licensed NSFileManager category for writing arbitrarily sized NSData as extended attributes by compressing it and then splitting it up if needed. http://skim-app.svn.sourceforge.net/viewvc/*checkout*/skim-app/trunk/NSFileManager_ExtendedAttributes.m It works great on HFS+, but there are some caveats: - creating a zip archive in Finder will destroy EA - creating a disk image of a file with hdiutil will destroy EA under some conditions - asr may lose EA (we had at least one report of install+migration failing) - various filesystems (e.g. AFP) have different size limits than HFS+ and IIRC the return value of the setxattr function won't tell you it failed in this case Lack of filesystem support will bite you with resource forks as well, but the first two are fixed in 10.5. It's still cleaner than messing with resource fork code, IMO, and for the common case it works very well. -- adam ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Resource Fork - is this a good use/the right thing to do?
On 4/23/08 1:21 AM, Daniel DeCovnick said: I'm writing an application that opens particular kinds of files, parses them, displays an editable graphical representation of the contents of a file, and saves the results of the changes to the file. However, some graphical changes don't result in changes to the original file, yet those changes need to be saved - a little bit analogous to the Finder saving the positions of icons in a window, but not changing the files themselves. This seems like a perfect use of package documents (a la .rtfd), except for one problem: the files I'm opening aren't mine, and should remain openable in other applications, so I can't wrap them up. I'd also really like to avoid making changes to the files themselves, at least the portions that their normal programs read. The Resource fork has been used for a long time for exactly that purpose. As others have said, extended attributes are another possibility. Both risk being clobbered by poorly written tools. Personally, I think a resource is a better idea. They're actually less likely to get clobbered as they have been around longer (you could even copy them to a Classic system, or 10.0, etc.). The Resource Manager is not deprecated and is even available in 64 bit (unlike other parts of Carbon). NDResourceFork provides a nice Cocoa wrapper over the C APIs. See: http://homepage.mac.com/nathan_day/pages/source.xml -- Sean McBride, B. Eng [EMAIL PROTECTED] Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Resource Fork - is this a good use/the right thing to do?
Another possibility is to write a short unique string (like a UUID) into an extended attribute, and then use that as a key into your own external data store, like a database or plist you put in some central place. A nice feature of this approach is that you only have to modify the file once, not every time your data changes. A drawback is that if the file is sent to somebody else, the information doesn't go with it. (Which, depending on what the info is, could be considered a benefit: people have gotten in trouble for forgetting about the metadata Word attaches to their documents.) —Jens smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Resource Fork - is this a good use/the right thing to do?
That's pretty much option 1, albeit implemented slightly more robustly than I was thinking of. But my data's not sensitive, so there's no advantage in losing it on sending it to someone else, and in fact I'd much prefer it was retained if possible. -Dan On Apr 23, 2008, at 11:10 AM, Jens Alfke wrote: Another possibility is to write a short unique string (like a UUID) into an extended attribute, and then use that as a key into your own external data store, like a database or plist you put in some central place. A nice feature of this approach is that you only have to modify the file once, not every time your data changes. A drawback is that if the file is sent to somebody else, the information doesn't go with it. (Which, depending on what the info is, could be considered a benefit: people have gotten in trouble for forgetting about the metadata Word attaches to their documents.) —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Resource Fork - is this a good use/the right thing to do?
Thirded. Matt Gough wrote: I'd second that. The OS (well, Finder) also adds things to the resource fork of files (custom icons, info about which app to open a file with when you changed it from the default etc). Just as long as you respect the existing contents this is exactly where you should put your data. On 23 Apr 2008, at 14:29, Ken Thomases wrote: On 23/04/2008, at 5:41 PM, Daniel DeCovnick wrote: Thanks for the suggestion. I've just looked through them now, as well as at the OSXBook (Mac OS X Internals: A Systems Approach by Amit Singh) info on that. In theory it looks good, but it's somewhat confusing. It looks like, at least in 10.4, except for the resource fork which is mapped as a fake xattr, you can only have inline attributes, with a length limit of 3802 bytes, and it would be quite common for my data to be significantly larger than that. Does anyone know if that's changed for 10.5? I say, if using the resource fork works for you, go for it. Whatever disadvantages there might be are 1) theoretical, and 2) no worse than extended attributes. No sense bending over backward to try to get some supposedly superior solution to work not quite as well as the resource fork would. That's my two cents, anyway. Cheers, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/matt.gough%40agfa.com This email sent to [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/jstiles%40blizzard.com This email sent to [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Resource Fork - is this a good use/the right thing to do?
That the Resource Manager is still around in 64-bit definitely alleviates one of my concerns - will whatever I use still be around in the future? Thanks much, Dan On Apr 23, 2008, at 10:12 AM, Sean McBride wrote: On 4/23/08 1:21 AM, Daniel DeCovnick said: I'm writing an application that opens particular kinds of files, parses them, displays an editable graphical representation of the contents of a file, and saves the results of the changes to the file. However, some graphical changes don't result in changes to the original file, yet those changes need to be saved - a little bit analogous to the Finder saving the positions of icons in a window, but not changing the files themselves. This seems like a perfect use of package documents (a la .rtfd), except for one problem: the files I'm opening aren't mine, and should remain openable in other applications, so I can't wrap them up. I'd also really like to avoid making changes to the files themselves, at least the portions that their normal programs read. The Resource fork has been used for a long time for exactly that purpose. As others have said, extended attributes are another possibility. Both risk being clobbered by poorly written tools. Personally, I think a resource is a better idea. They're actually less likely to get clobbered as they have been around longer (you could even copy them to a Classic system, or 10.0, etc.). The Resource Manager is not deprecated and is even available in 64 bit (unlike other parts of Carbon). NDResourceFork provides a nice Cocoa wrapper over the C APIs. See: http://homepage.mac.com/nathan_day/pages/source.xml -- Sean McBride, B. Eng [EMAIL PROTECTED] Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Resource Fork - is this a good use/the right thing to do?
Coincidentally I just went through that same song and dance. With Spotlight becoming more and more important in OSX, it is surprising Apple has not provided a clean method to store arbitrary metadata with any kind of file. Maybe time for us all to file an enhancement request. As others have mentioned, all currently available methods have drawbacks: - resource fork: Antiquated, entire data has to be read and stored back to even change a flag, creeping feeling they might be dropped at some point, care has to be taken which tools are used to process the files so resource fork is not lost. - xattrs: limited storage per attribute, tools may loose them. - Other approaches like db, links, hidden files etc: Separation of file and metadata, no support by standard tools, synching is tricky. Adobe attempted to solve the dilemma for graphic files by introducing XMP (http://www.adobe.com/products/xmp/), but it suffers from serious drawbacks: - Not a generic solution - Entire files have to be rewritten to modify metadata - Adding the metadata in some file formats seems like a hack, and has limitations that are dependent on the file format - Overly complicated and limiting storage schema - SDK seems overly complicated (mildly speaking) and still lacking core functionality Of course there are advantages to: - Platform independent - Metadata stays with files, no special knowledge required by file- handling tools, file systems or OS But overall no clear winner. Only option is to analyse one's design goals, and pick the lesser of the evils. In my opinion the best hypothetical solution would be if each file comes with a related directory that allows for storage of arbitrary metadata. However the hurdles of introducing something like that are enormous: All tools (simple tools like cp, complexer tools like tar, zip, rsync) would need to add support, and ways to make storage on alien file systems and efficient use through network file systems would have to be found. With metadata becoming more and more important in daily use it would be great if a platform independent way of storing metadata would be devised. But I am not holding my breath. In the mean time we all muddle along with our individual solutions... Another, though related, issue is that spotlight importers still can not be cascaded. Even just adding a few simple fields of metadata to an existing file format means one has to re-implement the importer for that format from scratch, no way of 'sub-classing' existing importers. Gerd (filing an enhancement request next) ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Resource Fork - is this a good use/the right thing to do?
Actually it is possible, at least according to the OSXBook, to add arbitrary key-value paired metadata to a file (IIRC, all MDItem keys share a flat namespace). It theoretically works without Spotlight, but nothing uses metadata that doesn't use Spotlight currently, AFAIK, and my data isn't anything that would be meaningful to anything or anyone outside of my app. It really is data rather than metadata. On Apr 23, 2008, at 12:41 PM, Gerd Knops wrote: Coincidentally I just went through that same song and dance. With Spotlight becoming more and more important in OSX, it is surprising Apple has not provided a clean method to store arbitrary metadata with any kind of file. Maybe time for us all to file an enhancement request. With metadata becoming more and more important in daily use it would be great if a platform independent way of storing metadata would be devised. But I am not holding my breath. In the mean time we all muddle along with our individual solutions... Another, though related, issue is that spotlight importers still can not be cascaded. Even just adding a few simple fields of metadata to an existing file format means one has to re-implement the importer for that format from scratch, no way of 'sub-classing' existing importers. Off-topic, but amen! -Dan ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Resource Fork - is this a good use/the right thing to do?
Am 23.04.2008 um 09:41 schrieb Daniel DeCovnick: Thanks for the suggestion. I've just looked through them now, as well as at the OSXBook (Mac OS X Internals: A Systems Approach by Amit Singh) info on that. In theory it looks good, but it's somewhat confusing. It looks like, at least in 10.4, except for the resource fork which is mapped as a fake xattr, you can only have inline attributes, with a length limit of 3802 bytes, and it would be quite common for my data to be significantly larger than that. Does anyone know if that's changed for 10.5? You may want to look at the size limits on resource forks, though. I thought I'd blogged about that ages ago, but can't find the posting right now. The resource fork format is documented, though, so it shouldn't be too hard to figure out. There's for example a 2727 resources limit on each file, and some offsets are 16-bit quantities. So, it's not really a good idea to have resources of several megabytes in size. Cheers, -- Uli Kusterer The Witnesses of TeachText are everywhere... http://www.zathras.de ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Resource Fork - is this a good use/the right thing to do?
Am 23.04.2008 um 17:10 schrieb Jens Alfke: Another possibility is to write a short unique string (like a UUID) into an extended attribute, and then use that as a key into your own external data store, like a database or plist you put in some central place. Not a good idea. The user could duplicate the file, and then both files would be associated with the same store entry... Cheers, -- Uli Kusterer The Witnesses of TeachText are everywhere... http://www.zathras.de ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Resource Fork - is this a good use/the right thing to do?
But the resource fork idea has the same issue if someone uses/sends/writes to the file from the other 90% of the computers on the planet... (windows). Doesn't it? I think you're best tracking the info in your own data source, doing your best to track and keep up with the user changing it outside your world, and leaving the original file alone. But like all the other suggestions here, that's just one opinion :) From: Daniel DeCovnick [EMAIL PROTECTED] Subject: Re: Resource Fork - is this a good use/the right thing to do? That's pretty much option 1, albeit implemented slightly more robustly than I was thinking of. But my data's not sensitive, so there's no advantage in losing it on sending it to someone else, and in fact I'd much prefer it was retained if possible. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Resource Fork - is this a good use/the right thing to do?
Am 23.04.2008 um 09:43 schrieb Daniel DeCovnick [EMAIL PROTECTED]: On Apr 23, 2008, at 2:07 AM, Jens Alfke wrote: On 22 Apr '08, at 10:21 PM, Daniel DeCovnick wrote: Through a lot of thought experiments, I've come to the conclusion that the best place to save this sort of thing would be in the resource fork of the file being opened, but I could be totally off the mark there, and it's certainly an unorthodox thing to do. It would have been the right thing to do ten years ago. But these days resource forks are definitely a legacy feature and it would be a bad idea to write new software that relies on them. Have you looked at Extended Attributes? They're kind of the moral equivalent of resources, but they're newer, lighter-weight and better integrated into the filesystem. I don't know if there's any in-depth documentation, but you can start by reading the man pages for getxattr, setxattr, et al. Thanks for the suggestion. I've just looked through them now, as well as at the OSXBook (Mac OS X Internals: A Systems Approach by Amit Singh) info on that. In theory it looks good, but it's somewhat confusing. It looks like, at least in 10.4, except for the resource fork which is mapped as a fake xattr, you can only have inline attributes, with a length limit of 3802 bytes, and it would be quite common for my data to be significantly larger than that. Does anyone know if that's changed for 10.5? Depending on your semantics you could always just save a UUID in an extended attribute and then associate that with your own storage mechanism. That should always fit the size limitations. To be more safe/compatible you could actually save the UUID as an extended attribute as well in a resource. When reading use either and reconsruct the missing one if necessary and possible. HTH Mike -- Mike Fischer Softwareentwicklung, EDV-Beratung Schulung, Vertrieb Note: I read this list in digest mode! Send me a private copy for faster responses. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Resource Fork - is this a good use/the right thing to do?
You may want to look at the size limits on resource forks, though. I thought I'd blogged about that ages ago, but can't find the posting right now. The resource fork format is documented, though, so it shouldn't be too hard to figure out. There's for example a 2727 resources limit on each file, and some offsets are 16-bit quantities. So, it's not really a good idea to have resources of several megabytes in size. I'm pretty sure the resource fork size limits are rather large... EV Nova's data files, in which everything is stored in the resource fork, go up to 13.8 MB. Also, it's a definite advantage that the resource fork is well-documented. That's more than one can say for xattrs, which are best documented in the OSXBook over a grand total of 3 pages. But the resource fork idea has the same issue if someone uses/sends/ writes to the file from the other 90% of the computers on the planet... (windows). Doesn't it? I don't think it does... doesn't NTFS have support for arbitrary named forks as well? At least to the point that it doesn't overwrite other forks when the data fork is written to? I mean, Windows can't read or write to them, AFAIK, but the low-level read/write routines should preserve it. I may be completely off base here, as I think I'm quoting a blog post, which may or may not have been a wishlist for Windows behavior. :-p To be more safe/compatible you could actually save the UUID as an extended attribute as well in a resource. When reading use either and reconsruct the missing one if necessary and possible. Unfortunately, as Uli pointed out, it's no longer unique if the file is duplicated. So I think that approach is out. -Dan ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Resource Fork - is this a good use/the right thing to do?
On 24/04/2008, at 11:53 AM, Daniel DeCovnick wrote: I'm pretty sure the resource fork size limits are rather large... EV Nova's data files, in which everything is stored in the resource fork, go up to 13.8 MB. Also, it's a definite advantage that the resource fork is well-documented. That's more than one can say for xattrs, which are best documented in the OSXBook over a grand total of 3 pages. The limits for resource forks are the same as for data forks. On HFS+ file-systems, they're stored in the same way as data forks are, whereas extended attributes are stored in the attributes file. You can still access the resource forks as if they were extended attributes. I don't think it does... doesn't NTFS have support for arbitrary named forks as well? At least to the point that it doesn't overwrite other forks when the data fork is written to? I mean, Windows can't read or write to them, AFAIK, but the low-level read/write routines should preserve it. I may be completely off base here, as I think I'm quoting a blog post, which may or may not have been a wishlist for Windows behavior. :-p NTFS does have support fro arbitrary named forks, but whether or not they're used depends on the implementation used to write them to an NTFS system. When OS X copies files with resource forks to file- systems that don't have support for resource-forks, I believe it creates an additional hidden file to store the data. The problem with these hidden files is that only OS X knows about them and so they'll not follow the file if you copy them using any other system. I don't know whether the SMB or read/write NTFS implementations used on OS X have proper support for resource forks (I doubt it). It doesn't look like the read-only NTFS implementation on OS X does. Sending files via e-mails doesn't work. FAT file-systems obviously don't. Unfortunately, as Uli pointed out, it's no longer unique if the file is duplicated. So I think that approach is out. Furthermore, it doesn't follow the file which was the original design goal. Going back to the original question, I personally think that the best thing to do is to just create another file and educate the user. Extended attributes and resource forks are all very nice but most users don't understand what they are and they just don't interoperate nicely with other systems. You can probably improve the user experience on OS X by storing the Catalog ID (as well as other details) of the file so that if the two files get separated you can easily find where it's moved to (assuming it's on the same file-system). - Chris smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Resource Fork - is this a good use/the right thing to do?
Chris Suter wrote: Furthermore, it doesn't follow the file which was the original design goal. Going back to the original question, I personally think that the best thing to do is to just create another file and educate the user. Extended attributes and resource forks are all very nice but most users don't understand what they are and they just don't interoperate nicely with other systems. My first thought on reading this thread is that it would be easiest just to store the data in a zip-type archive file. You could then have all the metadata/resource files included in an archive subdirectory, and everything would transfer nicely across operating systems. OpenOffice.org does this. All of the components of a document are stored in a zipped archive that just happens to have the .odt or .od-whatever extension. Using an archive file format solves the issue of user education, since it appears to be a single file to the user, gives the programmer the option of including whatever arbitrary resources are needed for this particular file, and also solves the issue of operating system portability, since just about any OS in current use can handle copying a binary file around. Just my 2d Cheers, Jason ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Resource Fork - is this a good use/the right thing to do?
The problem with that is, as I wrote in my first message, the real data files aren't mine, and won't be opened by my app exclusively. The data that I need to save ought to be invisible to the file's owner. Imagine, for example, that when working on a file in HexEdit, it allowed you to highlight in different colors and annotate locations in a file. Where would HexEdit save those annotations and locations and colors of highlighted areas? -Dan On Apr 23, 2008, at 11:33 PM, Jason Stephenson wrote: Chris Suter wrote: Furthermore, it doesn't follow the file which was the original design goal. Going back to the original question, I personally think that the best thing to do is to just create another file and educate the user. Extended attributes and resource forks are all very nice but most users don't understand what they are and they just don't interoperate nicely with other systems. My first thought on reading this thread is that it would be easiest just to store the data in a zip-type archive file. You could then have all the metadata/resource files included in an archive subdirectory, and everything would transfer nicely across operating systems. OpenOffice.org does this. All of the components of a document are stored in a zipped archive that just happens to have the .odt or .od-whatever extension. Using an archive file format solves the issue of user education, since it appears to be a single file to the user, gives the programmer the option of including whatever arbitrary resources are needed for this particular file, and also solves the issue of operating system portability, since just about any OS in current use can handle copying a binary file around. Just my 2d Cheers, Jason ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/danhd123%40mac.com This email sent to [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Resource Fork - is this a good use/the right thing to do?
I'm not sure what is all about
all resources can be stored in the data fork
resource manager perfectly understands it
there is no reason whatsoever to use resource fork.
you can easiliy convert old resource file (with resources in the
resource fork)
to resource file with resources in the data fork
Resorcerer, for example does it
you can write small application that will do that too
look, for example at the following code, that copies data fork of the
file specFile (resFork = false)
or copies resource fork of the file specFile (resFork = true)
to the normal data fork file.
copied resource fork will be perfectly usable in Xcode
Resorcerer will open it as well
OSErr CopyFork(FSRefPtr specFile, bool resFork) {
OSErr err = noErr;
HFSUniStr255dataForkName;
err = FSGetDataForkName(dataForkName);
if(err != noErr) return err;
HFSUniStr255resForkName;
err = FSGetResourceForkName(resForkName);
if(err != noErr) return err;
SInt16 fileFork = -1;
HFSUniStr255fileName;
FSRef parentRef;
err = FSGetCatalogInfo(specFile, kFSCatInfoNone, NULL, fileName,
NULL, parentRef);
if(err != noErr) return err;
CFStringRef newFileName = NULL;
CFStringRef cfFileName =
CFStringCreateWithCharacters(kCFAllocatorDefault, fileName.unicode,
fileName.length);//CFString.h
if(cfFileName != NULL) {
CFMutableArrayRef tempArr =
CFArrayCreateMutable(kCFAllocatorDefault, 2, kCFTypeArrayCallBacks);
CFArrayAppendValue(tempArr, cfFileName);
CFArrayAppendValue(tempArr, (resFork) ? CFSTR(rsrc) :
CFSTR(data));
newFileName =
CFStringCreateByCombiningStrings(kCFAllocatorDefault, tempArr,
CFSTR(.));
CFRelease(tempArr);
CFRelease(cfFileName);
}
if(newFileName == NULL) return coreFoundationUnknownErr;
err = FSOpenFork(specFile,
(resFork) ? resForkName.length :
dataForkName.length,
(resFork) ? resForkName.unicode :
dataForkName.unicode,
fsRdPerm, fileFork);
if(err == noErr) {
SInt16 outFile = -1;
FSRef newFSRef;
CFIndex length = CFStringGetLength(newFileName);
UniChar *buffer = new UniChar [length];
CFStringGetCharacters(newFileName, CFRangeMake(0, length),
buffer);
err = FSCreateFileUnicode(parentRef, length, buffer,
kFSCatInfoNone, NULL,
newFSRef,NULL);
if(err == dupFNErr) {
err = FSMakeFSRefUnicode(parentRef, length, buffer,
kTextEncodingUnknown, newFSRef);
}
delete [] buffer;
err = FSOpenFork(newFSRef, dataForkName.length,
dataForkName.unicode, fsWrPerm, outFile);
if(err == noErr) {
ByteCount actualCount = 0;
SInt64 positionOffset = 0;
ByteCount requestCount = 1024;
Byte *fileBuffer = new Byte [requestCount];
while(err == noErr){
err = FSReadFork(fileFork,fsFromStart,
positionOffset, requestCount, fileBuffer, actualCount);
if(actualCount 1) break;
positionOffset += actualCount;
OSErr writeErr = FSWriteFork(outFile,fsAtMark,0,
actualCount, fileBuffer, NULL);
if(writeErr != noErr) err = writeErr;
}
delete [] fileBuffer;
FSCloseFork(outFile);
}
FSCloseFork(fileFork);
}
CFRelease(newFileName);
return err;
}
On Apr 23, 2008, at 11:55 PM, Daniel DeCovnick wrote:
The problem with that is, as I wrote in my first message, the real
data files aren't mine, and won't be opened by my app exclusively.
The data that I need to save ought to be invisible to the file's
owner.
Imagine, for example, that when working on a file in HexEdit, it
allowed you to highlight in different colors and annotate locations
in a file. Where would HexEdit save those annotations and locations
and colors of highlighted areas?
-Dan
On Apr 23, 2008, at 11:33 PM, Jason Stephenson wrote:
Chris Suter wrote:
Furthermore, it doesn't follow the file which was the original
design goal.
Going back to the original question, I personally think that the
best thing to do is to just create another file and educate the
user. Extended attributes and resource forks are all very nice but
most users don't understand what they are and they just don't
interoperate nicely with other systems.
My first thought on reading this thread is that it would be easiest
just to store the data in a zip-type archive file. You could then
have all the metadata/resource files included in an archive
subdirectory, and everything would transfer nicely across operating
systems. OpenOffice.org does this. All of the components of a
document are stored in a zipped archive that just happens to have
the .odt or .od-whatever extension.
Using an archive file format solves the issue
Re: Resource Fork - is this a good use/the right thing to do?
On 24 Apr 2008, at 12:59 pm, Chris Suter wrote: The limits for resource forks are the same as for data forks Not true - the ResourceMap contains some 24-bit pointers, or at least it used to, as well as some 16-bit length fields as well. Unless these have been changed (possible I guess, I don't know) these will bite you before the file fork limitations do. G. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Resource Fork - is this a good use/the right thing to do?
On 24/04/2008, at 2:28 PM, Graham Cox wrote: On 24 Apr 2008, at 12:59 pm, Chris Suter wrote: The limits for resource forks are the same as for data forks Not true - the ResourceMap contains some 24-bit pointers, or at least it used to, as well as some 16-bit length fields as well. Unless these have been changed (possible I guess, I don't know) these will bite you before the file fork limitations do. I'm sorry, but it is true. We're not talking about ResourceMaps, we're talking about resource forks. ResourceMaps are just one thing that you might store in a resource fork but I don't know of any reason why you can't store anything you like in them and the limits for a resource fork are the same as those for a data fork. - Chris smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Resource Fork - is this a good use/the right thing to do?
On 24 Apr 2008, at 2:46 pm, Chris Suter wrote: On 24/04/2008, at 2:28 PM, Graham Cox wrote: On 24 Apr 2008, at 12:59 pm, Chris Suter wrote: The limits for resource forks are the same as for data forks Not true - the ResourceMap contains some 24-bit pointers, or at least it used to, as well as some 16-bit length fields as well. Unless these have been changed (possible I guess, I don't know) these will bite you before the file fork limitations do. I'm sorry, but it is true. We're not talking about ResourceMaps, we're talking about resource forks. ResourceMaps are just one thing that you might store in a resource fork but I don't know of any reason why you can't store anything you like in them and the limits for a resource fork are the same as those for a data fork. - Chris Sure, the fork limitations are the same. But the OP was talking about storing data in the Resource Fork as a resource (correct me if I'm wrong, I've only been following the thread peripherally) so ResourceMaps do come into it. G. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
