This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
Re: [corinna-cygwin@cygwin.com: Re: ENOTSOCK errors with cygwin dll 1.3.21 and 1.3.22]
At 01:16 PM 5/26/2003 +0200, Corinna Vinschen wrote:
>I've checked in a patch to fhandler_socket::connect() and
>fhandler_socket::accept()). Could you test it please? Basically it's
>just checking for WinSock2 availability before calling sock_event::load()
>and sock_event::wait().
>
Sure Corinna, will do.
BTW I saw your work on sparse files. It's extremely close to what I had
in mind. Here are a few comments for your consideration.
1) The way I think you have it, a file can be made sparse even when
O_CREAT | O_TRUNC isn't set. Is that desirable?
I was planning to do it as follows: instead of having the new member
fs_flags,
reuse FH_SHUTRD = 0x08000000 and define FH_SPARSEOK (note that
FH_SHUTWR is
already reused).
The FH_SPARSEOK bit is then set in fhandler_disk_file::open, in situations
where the file would previously be made sparse. So I was preserving the
previous logic.
2) in fhandler::write, test wincap.has_lseek_bug before the sparse file.
This is to cover the (hypothetical, so far) case where a win 95 would
mount a
remote file system supporting sparse files. I don't know if fs_flags
would show the file can be sparse, nor if the win95 lseek bug would
actually
show up. So it may be paranoia.
3) also around the same spot, test the FH_SPARSEOK bit (instead of fs_flags)
and clear it when making the file sparse.
4) I did some experiments on Win2000 with 4k clusters. The hole had to be
> 128kB before groups of 16 clusters would be skipped. Have you observed
skipping at 64kB?
5) Not related, there is a bug on line 209 of fhandler.cc. test for size,
not upper1.
Pierre