On Mar 2 12:03, Jason Winter wrote: > If you could look into that it would be great. I know there's a few > 'Hercules mainframe' emulator users who would like to get their tape drives > working, and I think this will fix it.
I've checked in a fix. Variable block reads should behave as on Linux now, reading only one block and returning its size. If the user supplied buffer is too small for the block, the block is read but read() returns ENOMEM. > You are right, I've not looked at the Cygwin source code... Only traced my > own programs to fix the difference I've discovered in the APIs. Could I > ask why you need to allocate a buffer and then copy it to the buffer I > supply? Wouldn't it be easier to calculate a new address when calling > ReadFile and do without the extra memcpy? Just thinking of speed, needless > mem-copies and needless buffers. Think a bit about the situation in general. Especially in cases where the user supplied buffer is smaller than the block size. Due to the above change, the variable block size reading doesn't need the internal buffer anymore but the static buffer size reads still need it. > If read() turns out to need a change, could you also check why I need to > set varblk mode before each write to remind the API what's going on - from > what I remember a second write returns an error unless I reset varblk mode > each time. (I call a routine to set to before each read and write, just to > be sure... but would like to know that all the extra code can be removed at > some time later.) Please provide a brief test case to reproduce that problem. I don't see that happening. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developer mailto:[EMAIL PROTECTED] Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
