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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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.
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
35 matches
Mail list logo
