fstat64 filesize problem

Vidar Hoel vhoel99 at grm.hia.no
Thu Feb 13 12:47:06 PST 2003

On Thu, Feb 13, 2003 at 03:51:24AM -0600, Kelledin wrote:
> On Thursday 13 February 2003 01:50 am, Vidar Hoel wrote:
> > To illustrate my problem, I have created a little program to
> > open one file:
> >
>  <snip>
> >     printf("Filesize: %ld\n", %buf.st_size);
>  whooops! ----------------------^
>  (yes, of course i can correct this on my end.  i did.)

I do not know how that came in there, must have been vim doing
something strange.

>  <snip more>
> > When I run this on several different boxes with strace (strace
> > ./stat stat.c), I get this output:
> >
> > open("stat.c", O_RDONLY)                = 3
> > fstat64(3, {st_mode=S_IFREG|0600, st_size=362, ...}) = 0
> >
> > And the value of st_size is correct, the file is 362 bytes
> > long.
> >
> > But, when I do the exact same on my LFS-box, this is the
> > output:
> >
> > open("stat.c", O_RDONLY)                = 3
> > fstat64(3, {st_mode=S_IFREG|0644, st_size=17592186044416,
> > ...}) = 0
> >
> > As you can see, the st_size is way off. But the output from my
> > program is correct. But some other programs (like metacity)
> > will complain (about empty XML-files), so this is a problem
> > for me.


> > BTW: The only main difference between my test-machines: The
> > LFS-box uses DevFS, but I can hardly think that make a
> > difference..
> It sounds like you're stumbling on a "large-file support" issue.  
> Compile the program with -D_FILE_OFFSET_BITS=64 
> should go away.  You'll know the problem is gone if 
> sizeof(buf.st_size)==8.

Well, I tried this, but no dice. I still have the same problem.
And, now I found a worse error: Trying to copy a file (via scp) from
this LFS-box, it would go in a loop and copy the file again and again

> I don't know why your other, non-LFS boxen would do large-file 
> support without needing those -D flags.  Are they some other 
> UNIX variant besides Linux?  Do they have 64-bit CPUs?  It's 
> possible that some distros make large-file support the default 
> on x86, but this is the Wrong Thing(tm) to do--x86 (being 
> 32-bit) takes a performance hit and loses some atomicity when 
> throwing around 64-bit ints vs. 32-bit ints.

They are both Linux, only my LFS has a bit newer glibc, gcc
and kernel (atleast now :-)) And all are x86, and distroes are
Slackware, Debian and Gentoo.

But thanks for the help anyways.. If you have any more ideas, let me
hear them!

Vidar Hoel - vhoel99 at grm.hia.no
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message

More information about the lfs-dev mailing list