bug#10733: 24.0.93; w32 file truncation

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: Eli Zaretskii <eliz@gnu.org>,  lekktu@gmail.com,  "Ota\, Takaaki" 
> <Takaaki.Ota@am.sony.com>
> Date: Mon, 06 Feb 2012 17:16:52 +0100
> 
> Óscar Fuentes <ofv@wanadoo.es> writes:
> 
> > I bet it is a bug on the CRT (the stat call that retrieves the file
> > size, to be precise). Maybe it is a MinGW thing.
> 
> No, it is an Emacs thing. `stat' is defined in lib-src/ntlib.c,
> overriding the MSVCRT implementation, which accounts for symlinks, while
> Emacs' does not.

Can you tell the details, please?  Specifically, what would it take to
"account for symlinks" in our implementation of `stat'?  You did say
symlinks were supposed to be transparent.

> Before the definition of `stat' on lib-src/ntlib.c there is this
> comment:
> 
> /* We need this because nt/inc/sys/stat.h defines struct stat that is
>    incompatible with the MS run-time libraries.  */
> 
> That looks like an understatement. Actually, we need our own stat
> function and struct because the `struct stat' that Emacs uses is
> incompatible with the one defined in MSVCRT, right?

No, you are missing the point of that comment.  lib-src/ntlib.c is not
compiled into Emacs, it's compiled into lib-src programs.
Theoretically, since those programs don't need anything fancy from
`stat', they could use the stock MSVCRT implementation.  But because
these programs are compiled with -I../nt/inc, the compiler picks up
the definition of `struct stat' that is used by Emacs, and because of
this incompatibility lib-src programs cannot use the MSVCRT
implementation of `stat'.

> The obvious fix does not seem difficult, although ugly and
> verbose.

Can you please describe the problem, in addition to what you propose
to be a solution?

> I'll like to remove the Emacs reimplementation of `stat'

That is a non-starter.  The private implementation of `stat' is needed
to support Posix features, such as meaningful inode numbers, UID and
GID, etc.  You won't find anything close to that in MSVCRT.  Quite a
few parts in Emacs expect those features.

> How much time we have until the release?

We cannot afford to make such a change before the release, no matter
how far away is it, even if I'd agree to that (which I don't).  `stat'
is too central to Emacs operation to make such changes at this time.

> BTW, the obvious fix may require some care for not breaking Emacs
> support on MS Windows versions prior to XP. We still support Windows 9x,
> don't we?

Yes, we do.  In fact, Emacs 24.1 will again work on Windows 9X, after
it turned out that 23.x (and perhaps also 22.x) didn't.