GNU bug report logs - #36940
tests slowness and failure after recent Tramp changes

Previous Next

Package: emacs;

Reported by: Paul Eggert <eggert <at> cs.ucla.edu>

Date: Tue, 6 Aug 2019 00:29:02 UTC

Severity: normal

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Stefan Kangas <stefan <at> marxist.se>, 36940 <at> debbugs.gnu.org
Subject: bug#36940: tests slowness and failure after recent Tramp changes
Date: Mon, 26 Aug 2019 10:44:06 +0200
Paul Eggert <eggert <at> cs.ucla.edu> writes:

Hi Paul,

> For example, suppose the inode number is 2**63 - 512 and the Perl code
> generates "9223372036854775296.0", which is exact. When the Emacs Lisp
> reader converts this to double it must round since there is no exact
> double representation, and rounding yields 2**63, i.e.,
> 9223372036854775808.0, which is off by 512.
>
> A simple fix is to change the Perl code to omit the trailing ".0",
> e.g., "9223372036854775296" rather than "9223372036854775296.0". This
> will cause the Emacs Lisp reader in master to return an exact integer
> instead of a float, thus avoiding the rounding error. This fix will
> still suffer from the same rounding errors in older Emacs releases
> where the reader returns a float for integers out of fixnum range, but
> it shouldn't hurt those older releases and it should fix the problem
> in master.

Indeed, up to Emacs 26 this rounding error still applies. With master
(improved big number support) it works fine.

> Please see attached patch. I haven't tested or installed the patch as
> I don't use Tramp, but you should be able to test it with something
> like this:

OK for me. You might install the patch, and also adapt the templates in
`tramp-do-file-attributes-with-stat and'
`tramp-do-directory-files-and-attributes-with-stat'.

>> I haven't seen any code in Emacs which needs this slot.
>
> It's used by ede--inode-for-dir, eshell-shuffle-files, ls-lisp-format,
> find-lisp-format, nnmaildir--group-maxnum,
> nnmaildir--new-number.

`ls-lisp-format' and `find-lisp-format' don't count, they *provide* the
inode number; they don't *use* it.

> Typical uses are to determine whether two
> directory entries identify the same file, e.g., (equal
> (file-attribute-inode-number file1) (file-attribute-inode-number
> file2)) or to use it in a hash table.

`ede--inode-for-dir' and `nnmaildir--*' are a little bit lazy, they
don't compare the device number. Might be acceptable; one could assume
that a project dir or a mail dir handle only files on the same file system.

Best regards, Michael.




This bug report was last modified 5 years and 326 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.