Am 19.10.2012 11:30, schrieb Le_Forgeron:

> Any clue why it might fails on Windows ?
> Does the lseek be deferred until actual usage ? (which write does)
> A packing issue with the array of long ? (but even if the written data
> are bogus, we asked for X bytes to be written, we should get X bytes
> written, no more, no less. (at worst, X could be shorter than the
> coverage of info[], or do you see a way to access bytes out of info[]
> scope ?)
> Or the call to write was interrupted ? (Windows actually has to allocate
> the whole file now on disk: if the allocation mechanism suck, it can
> take a lot of time: it has to write allocated and write all the needed
> sectors, that's a write of 2.4G file here... windows is not know to
> handle such request (of nearly empty file) as lightly as linux
> (according the actual filesystem, linux might just somehow fake it with
> an hollow file, whereas Windows will actually make the plain file right
> now: with a write to disk at 50MB/s (my reference for hard disk speed
> I/O), that's about 45 seconds of optimal I/O... may be more, as there is
> also the underlying filesystem structures to update)
>
> Is there on Windows a limit to the filesize that a user can create ?
> (man of write talk about RLIMIT_FSIZE resource)
>

FWIW I've just created a 16000x9800 pixel file (an OpenEXR, but PNG 
works the same) with 3.7RC6 msvc10.win64 and Windows 7 without any problems.
And the delay between parsing (not much to parse) and the render start 
was about 3 seconds.

-Ive

Post a reply to this message