[Bug 28665] ntdll/directory test fails on FreeBSD9

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=28665

--- Comment #24 from Charles Davis <cdavis5x at 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 at 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 at pcbsd-7162] ~/wine-git/dlls/ntdll/tests% echo $?
> > 0
> > 
> > [austin at 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 at 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.

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.