On 2000-07-11 10:32:37 +0200, Martin [Keso] Keseg wrote:
>> Note that this cache invalidation is _not_ an error.
>> In fact, some Linux versions incorrectly used cached
>> data, which reportedly lead to mail loss in several
>> cases.
> Isn't better to test for host enviroment and make
> decision on result ? For example use cache if host
> system is solaris or another unix with good caching.
I don't understand. The Linux problem was that fcntl did
_not_ invalidate the cache. How do you define "good
caching" here?
What currently happens is that mutt's fcntl locking just
works as intended, i.e., the client is guaranteed to read
the actual file content as present on the server.
Imagine new mail is appended to an mbox folder on the NFS
server, and the mbox folder is cached on the NFS client.
Now, the user tells mutt to synch the folder. To do this,
mutt will re-write the folder. If the NFS client's idea
of the mail folder isn't updated while locking, the
newly-delivered message will be lost. If Solaris' NFS
caching is able to catch such situations and not to fool
applications running on the client, it would be the OS's
job to re-validate the cache instead of invalidating it
upon locking. I don't believe there's anything mutt could
do about that. It has to happen in the file system
implementation.
--
Thomas Roessler <[EMAIL PROTECTED]>
