On Jan 24, 2007, at 11:31 PM, Doron Cohen wrote:
You could easily fix this by having the reader create a hard link
to the
index file. e.g.
ln foo foo-client.my.org-$$
open("foo-client.my.org-$$");
....
read()
...
close()
rm foo-client.my.org-$$
What happens when a client exits prematurely (without removing the
hard
link)?
The implication of the above is that the pid ($$) is included in the
hard link filename. We can go farther and put add a hostId and an
increment, too. That way, if a reader reconnects, it can scan file
names for matching hostIds, and if zap them if their pids aren't
active. If the host never reconnects, you get dead files, though.
Manageable I think, but complex, fragile, and icky. I don't think
the fellow who suggested this grokked how many files are involved or
how often we have to perform open/close ops.
Another drawback of this scheme is that it requires that the reader
app possess write permissions on the index directory, or at least the
NFS volume. One limitation of hard links is that you can't create
one pointing to an NFS file on your local file system.
Another problem: how would you do this sort of thing from Java? I
googled '"hard link" Java' and didn't come up with anything. I found
one forum entry where it was asserted that Java wouldn't support this
kind of system-specific IO op out of principle. Somebody school me
on how you'd implement it, please. From C, the POSIX function link()
is available from <unistd.h> -- would you have to call out to that?
Using a sequence of shell commands as per the example seems less than
ideal. :)
On the plus side, this is exactly the right remedy in theory. delete-
on-last-close is effectively a reference counting scheme. So is
this. I'm just waiting for the right variant of it to present itself.
Marvin Humphrey
Rectangular Research
http://www.rectangular.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
