[flac-dev] Windows file buffering

[LRN]

On 10.12.2015 19:58, lvqcl wrote:
> LRN wrote:
> 
>> The commit mentioned in the feature request should not cause such
>> behaviour, as it only does short-lived operations (opens a file, does
>> stuff, closes the file immediately after) and is clearly distinguishing
>> between disk files and pipes (which is how you, presumably, stream data to
>> other processes for whatever reasons).
>>
>> I don't claim that FLAC doesn't do buffering, as the OP described, just
>> that this commit is unlikely to be the cause.
> 
> Maybe you mean some other commit? For example,
> <http://git.xiph.org/?p=flac.git;a=commitdiff;h=d66f6754bf94bc8ba23d3579d0b5650cd380c9f0> ?
Yes, that is exactly what i meant.

> 
> The attached patch *should* resolve the issue. libFLAC will call setvbuf(file, ...)
> only if GetFileType(...file...) == FILE_TYPE_DISK.

That patch looks correct. That said, i'm not sure why there's setvbuf() in
the first place. I mean, the code to de-fragment the output file already
exists (the aforementioned d66f675), so why buffering? Was it proven
empirically that buffering is required? Or am i looking at this backwards
and that code was added later than setvbuf()?

-- 
O< ascii ribbon - stop html email! - www.asciiribbon.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20151210/58e8f466/attachment-0001.pgp