Mail Archives: cygwin/1997/01/09/09:23:31
>
> On Wed 8 January 1997, A. Phillip Smith
> <asmith AT www DOT aeinc DOT com> wrote:
>
> >
> >Has *anyone* been successful in porting GDBM 1.7.3 to run under Cygnus
> >b17.1 ?
>
> Not that I know of, however :
>
> -> There is a `native' precompiled port available from simtel.
> -> I have succeeded in porting db 1.85.5 (nothing other than the B-Tree
> code has been tested at all, and the B-Tree code hasn't been tested very
> thoroughly. I'm going to contribute it back when I have a spare minute,
> but if you ask me by mail I can send you a tar of the source tree now),
> which might provide the features you need.
>
> >I'm pretty far along with a port (i.e., everything compiles/links),
> >but there are a few low level problems in conjunction with partial writes
> >(possibly due to fsync bugs). They apparenty are the cause of partial read
> >errors. Under Unix, the system guartantees that the number of requested
> >bytes is returned if they are available in the file. Gdbm fails to get
> >the requested number of bytes in a single read. This may be the problem,
> >OR the cached data may not be written back to the file due to a broken
> >fsync(), thus causing the read errors. I have more debugging/tests to
> >further isolate it.
>
> Hmmm. I had a similar problem with db in that it didn't include
> O_BINARY in its open() call, so when it encountered a ^Z it would
> stop reading. This had predictable effects on database integrity.
>
> ISTR not being able to find fsync() at all (I had to remove the call
> and assume the system wasn't going to crash) - presumably there's
> a header file I'm missing ?
>
>
> [snip]
>
>
> Richard.
> -
> For help on using this list, send a message to
> "gnu-win32-request AT cygnus DOT com" with one line of text: "help".
>
Thanks. That's a reasonable suggestion, but it didn't help. I've even
compiled gdbm 1.5 which is already ported natively and works fine. It
uses O_BINARY and has MSDOS specific code, which compiles, links and
runs under cygnus, but exhibits the same behaviour... This DOES fix
the short reads, but apparently not all data is being written, so
fsync may still be a problem.
-
For help on using this list, send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
- Raw text -