On Sep 23, 2010, at 13:22 , Simon King wrote:
> On 23 Sep., 21:11, Simon King <simon.k...@nuigalway.ie> wrote:
>> ...
>> I would expect that F.close() waits until the file F really is closed,
>> but perhaps I am mistaken?
For most unix-like systems, it's generally not true that a close() of a file
descriptor will wait until the file is closed. The file may be open in
multiple processes or threads, so the close just decrements a "hold count".
Then there's the fact that closing a file on-disk is a multi-stage affair, and
that in a sense, it's not really closed until all the appropriate disk blocks
have actually been physically written to the "platters" on which they reside.
File operations are generally asynchronous.
In the interest of obsessive completeness (without claim of completeness), one
exception is the (last) close on a device (like a tty) that has a state
transition that is required for correct operation: the driver will hold the
calling thread in abeyance until the proper state is reached.
>> Anyway, it does occasionally happen to me (but it is hardly
>> reproducible) that the temporary file is mutilated when
>> self._eval_line(self._read_in_file_command(tmp_to_use),
>> allow_use_file=False) is executed. Is there a way to test whether the
>> creation of the file succeeded (and wait if it isn't done yet), before
>> trying to read it?
>
> Would it make sense to call os.fsync(F) after F.close()?
I would think that doing this will only cause an error of some sort to be
handed to your code: 'F' is not associated with anything after the close, so
"os.sync(F)" would be essentially meaningless to the kernel.
To your problem with corruption, if you are opening a new file descriptor for a
file that you are writing with an existing file descriptor, you are asking for
trouble, particularly if Python (or some library between your code and Python
or the kernel) is caching. Consider this:
You write to the file descriptor
Python holds onto the data for a while
You open a new descriptor on the same file
Python reads in what's there
Now you have two internal (to Python) copies of data from the same file that
differ. Wash rinse repeat.
I don't know enough about the rest of the system or your code to be sure this
is what's happening. If you haven't already, try F.sync() (or os.sync(F))
before closing the file. That may close the window where corruption can occur.
I hadn't been following the thread so I'm not sure whether you're already
doing this.
Another hack: try pausing before accessing the file after the close, so you're
(more) sure that the close has had an effect before proceeding.
HTH
Justin
--
Justin C. Walker, Curmudgeon at Large
Director
Institute for the Enhancement of the Director's income
-----------
--
They said it couldn't be done, but sometimes,
it doesn't work out that way.
- Casey Stengel
--
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
