Re: file sizes shown incorrectly for large files under Windows

[Jason Rumney]

Chris Moore wrote:

> Jason Rumney writes:
>
>  > I may be mistaken about the source of the inclusion of wchar.h, but
>  > stddef.h certainly does not include sys/stat.h on any set of
>  > headers I have.
>
> My mistake.  stddef.h *isn't* including stat.h on my system either.
> I don't know how, but I got confused.  stat.h includes stddef.h, not
> the other way around.
>
> Further investigation shows that it's emacs/src/s/ms-w32.h that
> includes stat.h for w32.c.

Ah! That explains it, I missed that reference. What happens if you take 
the include out of there and put it in w32.c?  If it still works, I 
agree with Eli that it is cleaner. My main concern was that adding 
stat.h would be misleading if the definition for stat was actually 
coming from somewhere else.

> However, other source files (buffer.c, for example) include <stat.h>

buffer.c is used by all platforms, so it makes sense that the include in 
s/ms-w32.h is not relevant there.

> It makes no sense for us to modify 'struct stat' if we don't modify
> the stat() function as well, does it?

I am not sure that it is a good idea to modify 'struct stat' at all now 
that I have thought about it. It is likely to introduce other bugs, and 
the 'long long' type that would have to be used is not compatible 
between different compilers. I am also not sure that this "bug" is 
confined to Windows, and any Windows specific redefinition would not 
solve the problem on other platforms.

Perhaps a better fix is for the Windows definition of stat() in w32.c to 
check nFileSizeLow, and set buf->st_size to ULONG_MAX when it is 
non-zero, so that files larger than 4Gb appear as 4Gb in directory 
listings instead of wrapping.