In article <51674ffc$0$29977$c3e8da3$54964...@news.astraweb.com>, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote:
> On Thu, 11 Apr 2013 19:55:53 +0000, Neil Cerutti wrote: > > > On 2013-04-11, Rob Schneider <rmsc...@gmail.com> wrote: > >> Thanks. Yes, there is a close function call before the copy is > >> launched. No other writes. Does Python wait for file close command to > >> complete before proceeding? > > > > The close method is defined and flushing and closing a file, so it > > should not return until that's done. > > But note that "done" in this case means "the file system thinks it is > done", not *actually* done. Hard drives, especially the cheaper ones, > lie. They can say the file is written when in fact the data is still in > the hard drive's internal cache and not written to the disk platter. > Also, in my experience, hardware RAID controllers will eat your data, and > then your brains when you try to diagnose the problem. > > I would consider the chance that the disk may be faulty, or the file > system is corrupt. Does the problem go away if you write to a different > file system or a different disk? It is *possible* that this is the problem, but it's really way far out on the long tail of possibilities. If the file system were corrupted or the disk faulty, the odds are you would be seeing all sorts of other problems. And this would not be anywhere near as repeatable as the OP is describing. Think horses, not zebras. -- http://mail.python.org/mailman/listinfo/python-list
