Re: testing exchangedata
Re: testing exchangedata
- Subject: Re: testing exchangedata
- From: glenn andreas <email@hidden>
- Date: Tue, 4 Oct 2005 13:27:23 -0500
On Oct 4, 2005, at 12:53 PM, Gerriet M. Denkmann wrote:
Yes. But in HFS(+) a hard link pointing to a file (with no other
hard links pointing to it) is something very different to just a file.
The problem is that no (known) Unix call can distinguish between
these two situations. The only (known) exception being exchangedata
which works onl in the second case.
That's not true - look at the code for exchangedata <http://
darwinsource.opendarwin.org/10.4/xnu-792/bsd/vfs/vfs_syscalls.c>.
There's really nothing special there - it does some basic "can I
access this file", some sanity check (same file system, not the same
file), and then calls VNOP_EXCHANGE. That calls the vfs layer to do
the work on that volume specific format. The distinction is subtle,
I know, but it's up to the volume specific code to determine how
these things are done (and one could imagine that there are file
system that don't have this problem).
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
from customers complaining that your application doesn't work when
editing files on some (for example) network file server, you need to
provide a fallback (so if exchangedata doesn't work because of extra
links, you'd use that anyway).
This is not a big problem, because exchangedata sets errno to
ENOTSUP in this case.
... and so if exchangedata set errno EINVAL (or whatever) you should
be able to handle it as well.
If it fails and _doesn't_ set errno, then that's a major problem.
Glenn Andreas email@hidden
<http://www.gandreas.com/> wicked fun!
quadrium | build, mutate, evolve | images, textures, backgrounds, art
_______________________________________________
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