Sorry to have to send a second response to this :-)
This will not work. No kind of dot-locking will work with an NFS client
that caches data, which includes Linux 2.0.x and Linux 2.1.x, unless you
are also doing something else I don't know about. Although dot-locking
will get you atomic access to the file, it won't make the order of reads
and writes around the lock atomic. It is very easy to lose mail this
way (30-60 second loss window), and very easy to verify the problem.
That this can happen despite locking is scary.
I'll repeat the bit from my recent posting
Subject: [PATCH] for lost mail due to NFS cache/locking non-atomicity
for your edification.
Tests
=====
I have tested for the problem and it is very easy to lose mail when you
know what order to do things in. I now believe I have lost mail in the
past because of this. (I didn't know it was likely before...)
It's easily tested. This is what I did with Mutt (should be similar
with Elm, Pine etc.):
1. Send myself a mail. Wait at least 60 seconds.
2. Start Mutt, see the mail with "N" flag.
3. Read mail, clears "N" flag.
4. Send myself a mail from within Mutt.
5. Synchronise mail folder ("$" key).
6. See that the second mail has got lost.
7. Repeat until convinced.
Extra steps include:
4a. Read mail on another machine, prove that the second mail did arrive.
6a. See that the second mail isn't visible on the other machine either.
8. Fix kernel (see below).
Enjoy,
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/