fstat64 filesize problem

Kelledin kelledin+LFS at skarpsey.dyndns.org
Thu Feb 13 01:51:24 PST 2003


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.)

 <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.
>
> I have tried to recompile both gcc, glibc and strace. I have
> tried to recompile reiserfsprogs without optimizations, to
> create a new partition with both ext3 and reiserfs to see of
> that helped, but no.
>
> Does anyone have an idea what is wrong, or what I might do to
> get this fixed? Anything will be appreciated!
>
> 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 
-D_LARGEFILE_SUPPORT -D_LARGEFILE64_SUPPORT, and this problem 
should go away.  You'll know the problem is gone if 
sizeof(buf.st_size)==8.

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.

-- 
Kelledin
"If a server crashes in a server farm and no one pings it, does 
it still cost four figures to fix?"

-- 
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