[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] tmpfs: now working
From: |
Niels Möller |
Subject: |
Re: [PATCH] tmpfs: now working |
Date: |
17 Apr 2001 14:38:47 +0200 |
Roland McGrath <roland@gnu.org> writes:
> file being truncated to zero and then enlarged. In fact, I believe (I'm
> not bothering to check POSIX even though the book is lying in front of me)
> the user is guaranteed that he can do:
If you ever bother to look it up, please let me know what you find.
(Or perhaps I should get that book for myself. What is a good POSIX
reference?)
> write(file, "data", size)
> ptr = mmap(file, 0, size)
> access ptr -- see "data"
> truncate(file) // could be ftruncate or via a wholly different peropen
> access ptr -- see SEGV(BUS?) in a specified manner
That is quite a harsh behaviour. If you're right, it seems impossible
(I prefer to classify tricks like catching SIGSEGV as impossible) to
write programs that use mmap and fail gracefully on all i/o errors,
bad data, etc. An alternative would be to keep a map of an all-zero
page if the file is truncated. Would it make sense to have a flag to
mmap that enables a different behaviour?
I'm also a little curious about how it works in practice, I've heard
reports saying that reading mmap:ed memory never results in SIGSEGV,
and others saying that it really did segfault under some version of
Solaris when mmap:ed NFS-mounted files were truncated.
I'd be grateful if you or some other knowledgable person could clarify
this.
Regards,
/Niels