Re: Can I flush the cache for an AFP volume?
Re: Can I flush the cache for an AFP volume?
- Subject: Re: Can I flush the cache for an AFP volume?
- From: James Bucanek <email@hidden>
- Date: Thu, 25 Sep 2008 12:41:31 -0700
Jim Luther <mailto:email@hidden> wrote (Thursday,
September 25, 2008 11:42 AM -0700):
You should use a client/server model so that all clients accessing the
data through the server (one access point to the file system). Anytime
you have shared access to a file on a network server volume from
multiple clients (or from an application on the server and a remote
client), you're in a race for that data. Exclusive access to a file is
the only way to prevent that problem and the only way to guarantee
that is a client server model where even a client running on the
server system goes through the server to access the data.
Not always an option.
A Time Capsule or Windows server can provide a shared AFP
volume, but I can't install my Cocoa-based server on either of
them. The application already uses exclusive access modes and
file locks to coordinate updates from multiple processes and/or
multiple remote clients. A client/server model is not the only
way to arbitrate concurrent access to a data file. The file
system provides numerous methods of controlling and restricting
access to files to avoid race conditions and interleaved update.
I'm already using those techniques, and they work dependably in
all cases except this one. I humbly submit that this is a flaw
in personal file sharing, not my application's architecture.
And just to make it clear, F_NOCACHE is a hint... not an order. If you
look at the corresponding bit in Files.h, kFSNoCacheBit, the comment
tries to make that clear by saying "please don't cache this request."
F_NOCACHE tells the file system that your application isn't going to
need the data read or written in the near future and so your
*application* doesn't need it cached. However, the file system may
still cache some or all of the data for its own reasons.
I was kind of afraid of that. fcntl() and PBHOpenDeny were
suggested on a macos-x-server list several years ago as a
workaround for this same problem.
Similarly, I already guessed that the various volume flush calls
probably wouldn't flush the read cache either. They seem
oriented to flushing unwritten data and syncing the disks.
Right now, I'm just telling the few users who are encountering
this problem to unmount their remote volumes between updates
(which are typically once a day).
--
James Bucanek
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden