We're guessing this has to do with some sort of file system caching before writing for optimized disk access. We'll probably add a simpler check of looking at the filesize after it's done (flushed/closed).
Of course. I think every Posix-style system optimizes disk access; I know that FreeBSD (and the other BSDs) and Linux both do. It's in the kernel, and would require a change to the kernel to make it work otherwise ... and of course it would slow down the system significantly, because heads are almost never where they need to be to optimize a disk write.
At the moment, DA does write to a 2nd file first, then move it in place of the original. This can still be used, but a "final disk size check" is likely the more reliable check (before the rename).
Are you using the equivalent of an
mv command, John?
If so consider that
mv command works differently depending on whether or not the file is being moved to the same partition.
If to the same partition, then mv simply changes the directory listing, then releases the space used in the old listing.
But if to a different partition, then mv works as a copy and then a delete. While I'm not sure exactly in what order a copy does things, I do know that a copy is not failsafe in the case of a full drive, so I'm guessing it deletes first, then writes, not necessarily to the same space, then changes the directory listing to point to where it just wrote.
So while creating a temporary file first sounds great, and while it proves there was space to do it when you do it, if the permanent file isn't in the same partition as the temporary file, then it doesn't prove there'll be space left for the permanent file (if for example, something fills up the drive between delete and the write.
Or of course it could write first, and then delete, but not know how to abort if it can't write.
Does anyone care to spend time chasing this down? I just tried and couldn't easily find the documentation.
Jeff
.