On 5/18/2011 15:53, Florian Pesth wrote:
> Granted, the described problem, that if a program opens before and writes
> after the lock (therefore overwriting the file) persists, but I don't
> think this is really a locking problem or is it?

That's not the only problem. The other problem is, as he said, taking down 
an NFS server from user mode, for example.

Here's the article I was thinking of:

http://0pointer.de/blog/projects/locking

http://0pointer.de/blog/projects/locking2

Contrast with (for example) mainframe locking, where advisory locks usually 
don't even use files, and mandatory locks are generally properly enforced 
because large amounts of peoples' money depends on them working. (Which is 
why all the stuff on Linux where peoples' money *does* depend on locking 
working, like an RDBMS, you access all the relevant files via a socket to a 
single process that does the locking without going through the file system 
to do so.)

And in the 1.x kernels (and maybe later), locking could also lead to 
starvation in Linux. It's all getting cleaned up over time, of course, but 
us old farts remember this stuff and are leery about anything new. Linux has 
it's own "wait for version 3 of anything MS releases".

Here's an exercise for you:
Write a backup program under Linux that correctly backs up files, even ones 
you might be editing, without ever losing both the new and old versions of a 
file.  I don't think that's possible.  I.e., I want to run a backup program 
using normal file system access (rather than reading raw disk data) that 
will reliably copy a local directory full of files, even if you're changing 
them. There's several ways of doing this on Windows. I don't know any way of 
doing it on Linux.

> Ok, thanks. I just was thinking of tailf which advertises with hard disk
> spin down when the file does not change

The hard disk spins down when the disk doesn't generate interrupts for some 
length of time. That doesn't mean there's no file activity. It just means 
all the file activity is using the buffers.

The three interfaces I remember are one that generates a SIGIO when your 
registered directory changes (which apparently nobody even talks about any 
more, but it was quite a ways back), dnotify (which required a separate file 
handle for each directory and communicates using signals, which means you 
can't really use threads to deal with it and you can't really be doing 
something else at the same time in the same process because a signal handler 
can't do I/O so you wind up polling to see if a signal happened), and 
inotify which finally got it right.

 > - so it definitely does not poll

That doesn't follow. The fact the disk spins down just means the kernel 
doesn't have to look at the disk to know the file hasn't changed.

> Has your problem something
> to do with blocking / non-blocking access of this information?

I don't really have a problem. We were just comparing areas in which Windows 
seems to do a superior job to Linux (or at least Linux as of not too long ago).

The dnotify is just an exceptionally kludgey interface, requiring one handle 
for each directory, "the problem of hard links to files has been ignored" 
(my favorite gripe about all UNIX kernel functionality), and requiring you 
to open each nested directory explicitly along with reading the entire 
directory every time a file changes to see what changed. That's why they 
replaced it. :-)

inotify is about as close as you're likely to get, letting you add the 
sockets to a select() list so you can (for example) wait for data from the 
keyboard while polling for directory changes.

None of them provide what Windows provides, which includes notifying you 
about changes since last you asked, even if you weren't running when the 
files changed.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message