From: "Ota, Takaaki" <Takaaki.Ota@am.sony.com>
To: <eliz@gnu.org>
Cc: ofv@wanadoo.es, lekktu@gmail.com, 10733@debbugs.gnu.org
Subject: bug#10733: 24.0.93; w32 file truncation
Date: Mon, 6 Feb 2012 12:19:53 -0800 [thread overview]
Message-ID: <20120206.121953.215407921.Takaaki.Ota@am.sony.com> (raw)
In-Reply-To: <83sjinbyez.fsf@gnu.org>
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
>
next prev parent reply other threads:[~2012-02-06 20:19 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-05 22:34 bug#10733: 24.0.93; w32 file truncation Ota, Takaaki
2012-02-05 23:51 ` Juanma Barranquero
2012-02-06 0:16 ` Ota, Takaaki
2012-02-06 4:05 ` Eli Zaretskii
2012-02-06 5:25 ` Óscar Fuentes
2012-02-06 16:16 ` Óscar Fuentes
2012-02-06 17:21 ` Eli Zaretskii
2012-02-06 17:58 ` Óscar Fuentes
2012-02-06 18:37 ` Eli Zaretskii
2012-02-06 20:19 ` Ota, Takaaki [this message]
2012-02-06 20:23 ` Lennart Borgman
2012-02-06 21:11 ` Eli Zaretskii
2012-02-06 21:20 ` Lennart Borgman
2012-02-06 21:31 ` Eli Zaretskii
2012-02-06 21:35 ` Lennart Borgman
2012-02-06 20:24 ` Lars Ingebrigtsen
2012-02-06 21:09 ` Eli Zaretskii
2012-02-06 21:08 ` Eli Zaretskii
2012-02-06 23:27 ` Óscar Fuentes
2012-02-06 23:43 ` Ota, Takaaki
2012-02-07 0:07 ` Óscar Fuentes
2012-02-07 4:02 ` Eli Zaretskii
2012-02-07 5:22 ` Óscar Fuentes
2012-02-07 17:35 ` Eli Zaretskii
2012-08-03 10:59 ` Eli Zaretskii
2012-02-06 16:55 ` Eli Zaretskii
2012-02-06 0:20 ` Óscar Fuentes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120206.121953.215407921.Takaaki.Ota@am.sony.com \
--to=takaaki.ota@am.sony.com \
--cc=10733@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=lekktu@gmail.com \
--cc=ofv@wanadoo.es \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.