Re: testing exchangedata
Re: testing exchangedata
- Subject: Re: testing exchangedata
- From: Derrick Bass <email@hidden>
- Date: Tue, 4 Oct 2005 13:02:09 -0500
Glenn Andreas wrote:
From a unix point of view, _all_ files are "hard linked" - if they
weren't, they wouldn't appear in the file system.
Basically, under UFS, a directory is a list of names and "i-node
numbers" (which refer to the actually file allocation blocks). So
Okay, we are straying far from Cocoa here but... almost all Mac OS X
users are using HFS+, not UFS, and the situation is a little
different there, because there is no notion of an inode in HFS+. All
the data that is stored in the inode under UFS is in the catalog file
in HFS+. Hard links were bolted-on to HFS+. When you make a hard
link, the OS moves the file to a special hidden directory, creates a
fake i-node number, and gives it a unique name like "iNode0123456".
Where the file originally was (as well as in the location of the new
link) is a special file containing this fake i-node number.
Additional links also reference the fake i-node number. When someone
tries to access a property of one of the links, the file system code
automatically looks up all the information in the hidden file
instead, so most programs never know they are looking at a hard-
linked file. So on HFS+, files with hard links are fundamentally
different from files without.
Now here's a key point for this discussion: let's say you remove all
but one link to a multiply-linked file. The file does not go back to
being a normal file. It is still stored in the hidden directory with
the funny name and the one remaining reference to it is still a
special file referring to the fake file. And exchangedata() fails to
work on such files. So even if you think exchangedata() should not
work on files with multiple links, there really should not be any
failure on singly-linked file, just because at some point in the
past, it was multiply linked. That part is definitely a bug.
Now I would argue that exchangedata() should also work on multiply
linked files; I prefer the first of your two scenarios, but
exchangedata() has an options parameter, so the decision could be
left to the programmer. I should also point out that however you save
a file on a UNIX system, you have to decide how to handle multiply-
linked files, so it's not like having exchangedata() fail on multiply-
linked files gets rid of the problem. (Really, the problem here is
actually in the semantics of hard-links. There are two different
meanings ("these are logically the same file" and "these files happen
to have the same data, so I'm saving some resources, but they are
logically different files") attached to the same implementation.)
So if exchangedata works, great, you're done. If it doesn't work,
you will still need provide fallback code to handle that case.
Disregarding the extra links issue, not all volumes support
exchangedata. So unless you like dealing with tech support calls
That's right, not all *volume types* support exchangedata(). But if a
volume supports it, it should support it for all files and not fail
unexpectedly for some. Moreover, the man page enumerates all possible
failures, and it does not mention the possibility of exchangedata()
failing on some valid files. (In fact, the error returned is -1,
unknown error.) So at the very least, this limitation needs to be
documented if Apple expects people to deal with it. And finally,
Apple's own applications use exchangedata and don't deal with the
problem. Xcode, for example won't save any edits to a file that has
or has even been hard-linked.
There's definitely a bug here. I think it's in exchangedata(); but
one could argue that the bug is elsewhere (i.e. in the man page and
in the behavior of pretty much all programs that rely on exchangedata
()).
Derrick
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden