Stat vs Stat64?

1,564 views
Skip to first unread message

Alex Blewitt

unread,
Feb 18, 2010, 8:27:02 PM2/18/10
to zfs-...@googlegroups.com
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

Mark Musante

unread,
Feb 18, 2010, 8:33:15 PM2/18/10
to zfs-...@googlegroups.com
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.

Jason Richard McNeil

unread,
Feb 18, 2010, 10:12:10 PM2/18/10
to zfs-macos
On Feb 18, 2010, at 6:27 PM, Alex Blewitt wrote:

> 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

Alex Blewitt

unread,
Feb 19, 2010, 7:22:48 AM2/19/10
to zfs-...@googlegroups.com, zfs-macos
We have some mixed uses in the code base at the moment. Quite a few of
the Solaris calls use stat64, and they've been worked around
(inconsistently) if a mixture of #ifdef __APPLE__ and the _DARWIN flag
you mention. Agree from the manpage we should be using the non64
variant, but I think we need to ensure consistency over the call sites
that use stat/stat64 to use that DARWIN flag.

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:

Alex Blewitt

unread,
Feb 20, 2010, 10:36:02 AM2/20/10
to zfs-...@googlegroups.com
On 19 Feb 2010, at 03:12, Jason Richard McNeil 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

Chris Ridd

unread,
Feb 21, 2010, 5:57:01 AM2/21/10
to zfs-...@googlegroups.com

On 19 Feb 2010, at 01:33, Mark Musante wrote:

> 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

Gary Gendel

unread,
Feb 22, 2010, 9:24:44 AM2/22/10
to zfs-macos
I did some greps for DARWIN and could only find the
_DARWIN_FEATURE_64_BIT_INODE used.

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

Reply all
Reply to author
Forward
0 new messages