Re: File locking with daemon/kext/application setup
Re: File locking with daemon/kext/application setup
- Subject: Re: File locking with daemon/kext/application setup
- From: Terry Lambert <email@hidden>
- Date: Fri, 08 Aug 2008 08:50:13 -0700
A deleted files space is not reclaimed until the last reference to it
goes away. An open is a reference, and a directory entry is a reference.
It is quite common for UNIX programs to create a temporary file, open
it, and unlink it, leaving it open, and use this as a means of having
the file get automatically cleaned up if the program crashes.
So you actually do not need to "detect" anything: your daemon will
have absolutely no problems continuing to read, write, extend,
truncate, map, or otherwise use the file contents, until the file is
closed.
-- Terry
On Aug 8, 2008, at 4:14 AM, Tim Schooley <email@hidden> wrote:
Hi all,
I'm sorry if this has been answered elsewhere, but I've spent too long
searching, and failed miserably to find the right answer.
I have the following setup:
- An IOBlockStorageDriver kext, that exposes block devices to the OS.
- A daemon (running as a LaunchDaemon) which handles all block IO, and
reading/writing the data to a file.
- A client application for configuring the above.
My problem is this:
When a file is "mounted" by the user, the daemon opens the file as
normal.
But the user can then remove the file from the terminal, and the
daemon will
be none-the-wiser.
I need a way to either:
a) lock the file from the daemon side that will prevent the user from
deleting the file (but allowing the user to _read_ the file). So
far, my
search for a solution on this has led me to believe that it isn't
possible.
"man chflags" does not list uulink as an option on 10.5.4, and I'm
not even
sure if the "rm" command would listen to it.
b) code the daemon to detect the file was deleted, so it can tear
down the
block device. I think this may make more sense, since it removes the
chance
of an application or utility not abiding by the rules of a locking
solution.
Or, if anyone has any suggestions, I'm all ears! Either way, it'd be
nice to
know what other peeps would do for this situation - maybe I'm missing
something fundamental.
Many thanks for any pointers.
Kind regards,
Tim
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden