>>>
>>>OK. Just a reminder - it's windows XP. fsize did the same thing as ADIR. Trying FOPEN next, but switched from that originally because of a suspected deadlock situation.
>>
>>Note that I said "fopen() read only" - and that'd be unbuffered as well. Since you aren't exactly reading anything, just doing a ?fseek(h, 0, 2) shouldn't hurt. I'm trying it with a similar process as I write this, and it seems to work, though the example is wrong - it's too fast and was finished before I could check whether it's reporting progress or not.
>
>FOPEN(m.lcFile,10) always reports -1. The file is being created by SQL Server - probably exclusive use.
>
>If was only ever able to use FOPEN as a means of checking if the file had been completely created. Until we ran into what looked like a deadlock.

Sheesh... it seems to be an OS thing. I've watched several processes over time (SQL backup, zipping, conversions) and the reported size of the file seems to vary in jumps, while the free space on the drive is refreshed more frequently. Probably depends on how often does the app flush its buffers. Some processes show a filesize of zero until the file is closed. I'm watching this from TotalCommander, and I'm pretty sure mr Ghisler didn't roll his own, but rather calls some OS API. In case of SQL backup, maybe that would be the way - as I see it changing size every few seconds, so there MUST be a way. Go to Anatoliy's website, he may have some GetFileSizeEx or something.