os.path.getsize() on Windows

[John Machin]

On Mar 19, 9:27 am, Sean DiZazzo <half.ital... at gmail.com> wrote:
> On Mar 18, 2:27 pm, Duncan Booth <duncan.bo... at invalid.invalid> wrote:
>
>
>
> > Sean DiZazzo <half.ital... at gmail.com> wrote:
> > > On windows, this returns the size of the file as it _will be_, not the
> > > size that it currently is.  Is this a feature?  What is the proper way
> > > to get the current size of the file?  I noticed
> > > win32File.GetFileSize()  Does that behave the way I expect?
>
> > > PS.  I also tried os.stat()[6]
>
> > I think all of those will return the current size of the file, but that may
> > be the same as the final size: just because the data hasn't been copied
> > doesn't mean the file space hasn't been allocated. You don't say how you
> > are copying the file, but I seem to remember that Windows copy command pre-
> > allocates the file at its final size (so as to reduce fragmentation) and
> > then just copies the data after that.
>
> > If you need to make sure you don't access a file until the copy has
> > finished then get hwatever is doing the copy to copy it to a temporary
> > filename in the same folder and rename it when complete. Then you just have
> > to check for existence of the target file.
>
> Hmmm... The file could be copied in by several different sources of
> which I have no control.  I can't use your technique in my situation.
> I also tried getting md5 hashes with some time in between on advice,
> but the file is not opened for reading until the copy completes so I
> can't get the hashes.
>
> Any other ideas?

Why not try to open the file for exclusive write/update access?