bug#10733: 24.0.93; w32 file truncation

[Ota, Takaaki]

For your information:

(file-attributes "memo")
(nil 1 544 513 (20269 7834) (20269 7834) (20269 7834) 0 "-rw-rw-rw-" nil (8448 
8 . 22758) (62004 . 15649))
(file-attributes "memo.old")
(nil 1 544 513 (19686 63524) (20262 20973) (19686 63524) 233153 "-r--r--r--" 
nil (512 5 . 24351) (62004 . 15649))

where "memo" is the NTFS symlink and "memo.old" is a real file.  I
don't know how the size 0 on symlink side is translated into 64K.

-Tak

Mon, 6 Feb 2012 10:37:56 -0800: Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Óscar Fuentes <ofv@wanadoo.es>
> > Cc: lekktu@gmail.com,  Takaaki.Ota@am.sony.com,  10733@debbugs.gnu.org
> > Date: Mon, 06 Feb 2012 18:58:15 +0100
> > 
> > >> /* 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'.
> > 
> > I think you are saying essentially the same as I do but with very
> > different words.
> 
> No, I'm not.
> 
> > OTOH, you are saying "lib-src/ntlib.c is not compiled into Emacs, it's
> > compiled into lib-src programs." and the key hypotheses made by me here
> > is that Emacs uses the `stat' definition on lib-src/ntlib.c. Is that
> > correct?
> 
> No.  The `stat' Emacs uses is in w32.c.  What you see on
> lib-src/ntlib.c is just a minimal subset of what we have in w32.c.
> 
> > Symlinks are detected and handled specially on MSVCRT's stat. In
> > aessence, for symlinks it uses fstat.
> 
> But fstat probably calls GetFileInformationByHandle under the hood,
> and we already call that function in w32.c:stat.  So maybe the fix is
> not as ugly and inelegant as you thought.
> 
> > > 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.
> > 
> > Such change would be conceptually straightforward and quite safe. It
> > amounts to using MSVCRT `stat' and translating its `struct stat' to
> > Emacs' `struct stat'. Instead of defining our own `stat' and `struct
> > stat' we define `emacs_w32_stat' and `struct emacs_w32_stat' and do
> > 
> > #if windows
> > #define stat emacs_w32_stat
> > #endif
> 
> This doesn't work.  I don't remember all the details at the moment,
> but it's not a coincidence we define `stat' in w32.c, not `sys_stat',
> as we do with other functions.  One immediate problem with this is
> that we also have our own implementation of `fstat' on w32.c, and they
> must both share the same `struct stat'.  It gets really ugly, believe
> me.
> 
> Anyway, I don't think we need to call MSVCRT's `fstat' to fix this,
> see above.
> 
> > I don't get your mention to inode numbers, UID and GID. The
> > implementation on ntlib.c simply does
> > 
> >   buf->st_ino = 0;
> > 
> > and I see no references to UID and GID.
> 
> See above: you are looking at the wrong `stat'.  The one that caused
> all this is on w32.c.
> 
> > >> 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.
> > 
> > So we are reintroducing support for a legacy OS after being de facto
> > removed for several years. Curious.
> 
> It wasn't a "removal", it was a tricky bug.
> 
> Anyway, see this discussion:
> 
>   http://lists.gnu.org/archive/html/emacs-devel/2011-07/msg00785.html
>   http://lists.gnu.org/archive/html/emacs-devel/2011-07/msg00827.html
>