http://bugs.winehq.org/show_bug.cgi?id=28665
--- Comment #24 from Charles Davis cdavis5x@gmail.com 2013-07-09 20:32:45 CDT --- (In reply to comment #23)
(In reply to comment #22)
(In reply to comment #21)
Created attachment 45087 [details] Patches to make tests pass on Mac OS and maybe FreeBSD
Works here: [austin@pcbsd-7162] ~/wine-git/dlls/ntdll/tests% time !make time make directory.ok ../../../tools/runtest -q -P wine -M ntdll.dll -T ../../.. -p ntdll_test.exe.so directory.c && touch directory.ok directory.c:292: Tests skipped: Wow64 redirection not supported 0.012u 0.036s 0:00.40 10.0% 119+3961k 0+0io 0pf+0w
[austin@pcbsd-7162] ~/wine-git/dlls/ntdll/tests% echo $? 0
[austin@pcbsd-7162] ~/wine-git/dlls/ntdll/tests% uname -a FreeBSD pcbsd-7162 9.1-RELEASE FreeBSD 9.1-RELEASE #2: Tue Nov 27 03:06:52 UTC 2012 root@darkstar:/usr/obj/pcbsd-build90/fbsd-source/9.1/sys/GENERIC i386
OK. I assume that was with UFS (the default FreeBSD filesystem), right? So now the question is: does it work with other filesystems on FreeBSD? (FAT (msdosfs) and CDFS (isofs or some such)
Actually, it's cd9660.
are probably good candidates. I read that FreeBSD wants an HFS+ driver, too; maybe they made some progress on that, and you may want to check with that, too. They said they wanted to use the Darwin driver as a base, though, so it might exhibit the same behavior as Darwin; see below.) If it doesn't... well, you know what to do.
A little technical background: my patch probably worked with UFS because on FreeBSD (and probably the other non-Darwin BSDs as well), the dirent structure is exactly the same as the on-disk structure used in UFS, so the seek offsets are just multiples of sizeof(struct dirent). (I know this because I studied FreeBSD's kernel sources when I was making this patch.) But on Darwin (and thus, Mac OS X), the seek offsets are completely arbitrary; with HFS, for example, it's the index of the directory entry OR'd with some sort of session ID in the upper bits. (Again, I figured that out studying the Darwin XNU kernel sources.) That's why the man page for getdirentries(2) on at least Darwin says you should only pass 0 and the offsets returned from either getdirentries(2) or lseek(2) when seeking on a directory FD, and that's why I needed to use getdirentries64(2) on Mac OS. Looks like I might need to do a little more digging in FreeBSD's kernel sources (and probably the other BSD kernels as well)... Oh well, off I go.
OK I'm back. (That was fast. :) And sorry about the double post.
It looks like FreeBSD's behavior is similar to Mac OS; offsets within a directory FD are arbitrary. On FAT, for example, they're in multiples of 32 bytes (the size of a FAT directory entry). LFNs (which take up multiple DEs) probably complicate this even more. I'm not quite sure what CDFS does on FreeBSD, even from reading the sources, but it's likely not the same as UFS or FAT. You're likely to encounter failures (or worse) testing this on non-UFS, so I'll try to set up a FreeBSD VM and see if I can't get this working. But without a 'd_off' (like Linux) or 'd_seekoff' (like Darwin) field, this might be insanely difficult.