http://bugs.winehq.org/show_bug.cgi?id=28665
--- Comment #20 from Charles Davis cdavis5x@gmail.com 2013-07-03 11:56:29 CDT --- (In reply to comment #18)
Thanks, but it doesn't look good. It seems every time it's seeked to 0 (the start), MacOS changes all dirent offsets (adds some random(?) base number), so I can't look up where the second entry is going to be to be able to do the swap trick that is done on Linux.
I've figured out what that is. HFS actually uses bits 26-31 of the offset (at least, with 32-bit getdirentries(2)) for some sort of session ID or some such. Every time the file pointer is reset to 0, this value is incremented.
And on BSD it looks like reading current pos with lseek is not even possible..
Hmm... That's funny, because at least on Mac OS, the manpage for getdirentries(2) recommends using lseek(2) to read the current offset (because the 32-bit getdirentries(2) doesn't support 64-bit offsets, unlike the rest of Darwin/XNU). Can't speak for FreeBSD, though.
(In reply to comment #19)
Still in 1.6-rc4: http://test.winehq.org/data/2d0653e2b2851131540a56d24950746dcca36a48/bsd_ae-...
I think I've figured out how to fix this. But the patch is really ugly, and there's another patch before it that needs to be applied for this to work right on Mac OS. (It uses the inode64 getdirentries64(2) syscall, which does exist, just without a syscall stub in libSystem. I used it because the inode64 struct dirent on Mac OS has a 'd_seekoff' field, like Linux's 'd_off' field.) Also, I only know for sure that they work on Mac OS 10.6; I haven't been able to test anywhere else where this would matter. (I did verify that the patch has no effect on Linux, if that makes the rest of the Wine community feel better. :)
I will attach my patches for your perusal. I doubt we'll be able to get them into Wine 1.6 now that we're in code freeze, but it's worth a shot to get those tests fixed.