[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#36940: tests slowness and failure after recent Tramp changes

From: Paul Eggert
Subject: bug#36940: tests slowness and failure after recent Tramp changes
Date: Sun, 25 Aug 2019 13:36:46 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

Michael Albinus wrote:

At which places in the code do you believe such errors will happen? The
floating number will be converted in tramp-convert-file-attributes, I
cannot see how a rounding error could happen there.

I think the rounding error doesn't happen there, as that code accurately converts the Lisp float to an integer or to a cons of integers. The rounding error happens in functions like tramp-send-command-and-read when the Emacs Lisp reader scans the string generated by the Perl code, and converts the string to a Lisp float.

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.

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:

$ echo '' | dd obs=1 seek=9007199254740992 of=file
0+1 records in
1+0 records out
1 byte (1 B) copied, 0.015429 seconds, 0.1 kB/s
$ ls -l file
-rw-rw-r-- 1 eggert faculty 9007199254740993 2019-08-25 13:28 file

assuming your filesystem supports files containing more than 2**53 bytes - since there's a similar bug for file sizes.

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. 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.

As I mentioned above, a similar bug occurs for the file size slot: files containing more than 2**53 bytes have rounding errors in their sizes. The attached patch should fix that too.

Attachment: 0001-Fix-Tramp-rounding-of-file-sizes-and-inode-numbers.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]