Alex
> Does anyone know what the difference between Stat and Stat64 is? There's a few places in the merge where the OSX code uses Stat, but the Solaris code uses Stat64. I'm also wondering whether this might be related to some of the issues I've seen with files apparently being out-of-date; perhaps there's codepaths with some parts returning/using a stat64 and some using a stat.
>
> Alex
My reading of the man page for stat64 on Snow Leopard seems to suggest that it's not necessary to use stat64 instead of stat if the _DARWIN_USE_64_BIT_INODE macro is set.
According to the fstat64 man page "The stat64(), fstat64(), and lstat64() system calls first appeared in Mac OS X 10.5 (Leopard) and are now deprecated in favor of the corresponding symbol variants."
So if you're going to support 10.5, you'll have to use the xxxxx64 variants if the _DARWIN_USE_64_BIT_INODE macro isn't defined on 10.5. On 10.6 I think it might be safe to use the usual calls.
-- jasonrm
I'm hoping to set up an automated build on 10.5 as well as 10.6 soon,
but will do so after the merge is done (last 90 files now ...)
If someone can file a Google Issue with this mail, that'd be great -
otherwise will do so tonight when I'm near a real keyboard/display.
Alex
Sent from my (new) iPhone
On 19 Feb 2010, at 03:12, Jason Richard McNeil <ja...@jasonrm.net>
wrote:
>
> My reading of the man page for stat64 on Snow Leopard seems to suggest that it's not necessary to use stat64 instead of stat if the _DARWIN_USE_64_BIT_INODE macro is set.
>
> According to the fstat64 man page "The stat64(), fstat64(), and lstat64() system calls first appeared in Mac OS X 10.5 (Leopard) and are now deprecated in favor of the corresponding symbol variants."
>
> So if you're going to support 10.5, you'll have to use the xxxxx64 variants if the _DARWIN_USE_64_BIT_INODE macro isn't defined on 10.5. On 10.6 I think it might be safe to use the usual calls.
I've raised Issue 28 for this:
http://code.google.com/p/maczfs/issues/detail?id=28
We seem to be inconsistently using it in the codebase at the moment. In some places, it's _DARWIN_FEATURE..., and in others, _DARWIN_USE.... Yet more involves __APPLE__ or some variant around the stat/stat64 boundaries.
If someone has time on their hands and wants to do a sweep of the codebase to improve (a) finding out which macro we should use, and (b) finding all references to stat/stat64 and surrounding them with the correct bracketing, that would be good. If you do, please assign the issue to yourself so that we know who's working on it (and if you're not on the project yet, drop me a mail to let me know so I can add you).
Alex
> stat64 uses 64-bit fields, which is handy if you have files bigger
> than 4gb. See http://docs.sun.com/app/docs/doc/816-0220/6m6nkorq1?a=view
> for detailed info.
Correct - Solaris (like many other Unixes needing backwards comaptibility) has a stat() call and a stat64() call which gets used for LARGEFILE-aware applications. OS X's system calls have *always* been LARGEFILE-aware (since at least OS X 10.0) so these calls are identical on OS X.
LARGEFILE means files with 64-bit sizes. 32-bit processes on Solaris can be LARGEFILE-aware. 64-bit processes are always LARGEFILE-aware.
Cheers,
Chris
From the getfsstat man page, I see that this macro is set on 10.6+ but
not on earlier versions. This indicates that there were changes to
the definition of the statfs structure. From that, I can imagine that
we should always be using _APPLE_ to change the stat64(), etc. calls
to their non-deprecated form. However, any time we need to actually
use the values in the statfs structure, we need the
_DARWIN_FEATURE_64_BIT_INODE to make sure we don't truncate things to
32 bit values which could cause some really bad things to happen.
Gary