On Tue, 24 May 2005, Timo Sirainen wrote:
On 18.5.2005, at 03:00, Todd Burroughs wrote:
That's a gdb bug (or gcc debug information writer bug or something). 64bit numbers seem to be quite often broken with gdb. Usually they can be fixed by just discarding the highest 32 bits, but with struct stat the whole st_size seems to points to wrong location.
Thanks, the gdb bug is good to know...
Right, I thought about this too after sending the mail. The caching problem could happen only if another computer modified the file, so the test program couldn't really trigger it.
I actually ran it on one machine and looked at the output from another. i.e., 'ls -l' on the empty file, then again just after running the program, all within a second. I don't know how the cache refresh timing works, but it did not cache the old attributes for the minumum of three seconds. Probably a good thing.
But included a patch to Dovecot, it should give some more information now instead of just crashing.
Found a small problem with the patch, but I think I've fixed it and we'll see what happens:
Compile errors:
mbox-sync.c: In function mbox_sync_handle_eof_updates': mbox-sync.c:1168: error: structure has no member named ibox'
mbox-sync.c:1170: error: structure has no member named ibox' mbox-sync.c:1174: error: structure has no member named ibox'
mbox-sync.c:1176: error: structure has no member named `ibox'
if (fstat(sync_ctx->ibox->mbox_fd, &st1) < 0)i_error("fstat(mbox) failed: %m");
I substituted 'mbox' for 'ibox'. I think that's what you meant?
Todd