• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: testing exchangedata
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: testing exchangedata


  • Subject: Re: testing exchangedata
  • From: "Gerriet M. Denkmann" <email@hidden>
  • Date: Tue, 4 Oct 2005 22:39:55 +0200


On 04.10.2005, at 21:02, glenn andreas <email@hidden> wrote:


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 only 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 sets errno EINVAL (or whatever) you should
be able to handle it as well.

Yes. But I want to know whether exchangedata will work (because the file saving machinery of NSDocument will be calling it).
In case it will not work, I want to put up some panel, or do some other actions.


Currently I do:
returnCode = exchangedata( my_file, some_dummy_file);
if ( returnCode == 0 ) exchangedata( some_dummy_file, my_file);
(if all is fine - which is the most probable case - I do two useless exchanges; also I think the dummy file is very ugly - and the idea that something bad might happen between these two exchanges makes me uneasy)
if ( returnCode != 0 && errno == EINVAL ) do something here
(another problem: EINVAL gets set for hard links, but also for other errors)


What I want is:
returnCode = thisIsAHardLink( my_file );
if ( returnCode != 0 ) do something here.

Maybe fsctl could help me? The man page mentions that requests are filesystem-specific but does not say what request one might make.
Do you have any further information on this?


What about getattrlist()?It has a rather overwhelming man page.


Kind regards,

Gerriet.

_______________________________________________
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


  • Follow-Ups:
    • Re: testing exchangedata
      • From: glenn andreas <email@hidden>
  • Prev by Date: Re: Getting an NSLocalizedString for another localization
  • Next by Date: Optimizing PDFKit
  • Previous by thread: Re: testing exchangedata
  • Next by thread: Re: testing exchangedata
  • Index(es):
    • Date
    • Thread