bugGNU tar - Bugs: bug #60948, Tar does not properly handle...

 
 

bug #60948: Tar does not properly handle "short reads", resulting in truncation

Submitter:  None
Submitted:  Tue 20 Jul 2021 07:29:42 AM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Sat 11 Feb 2023 01:16:07 PM UTC, comment #2: 

I'm closing it, since the issue has been discussed in detail in https://lists.gnu.org/archive/html/bug-tar/2021-07/msg00001.html.

Sergey Poznyakoff <gray>
Group administrator
Tue 20 Jul 2021 10:59:27 AM UTC, comment #1: 

Apparently this has also been posted to the mailing list by the 9p maintainers: https://lists.gnu.org/archive/html/bug-tar/2021-07/msg00001.html

I was not aware of that thread when reporting this bug, sorry about causing redundant traffic.

Anonymous
Tue 20 Jul 2021 07:29:42 AM UTC, original submission:  

I reported a bug to the QEMU project about tar being unable to read more than 4096 bytes from files from the 9p filesystem, see https://gitlab.com/qemu-project/qemu/-/issues/409 for details.

The maintainers of 9p concluded that this is caused by a bug in tar. Quoting Christian Schoenebeck's comment:

"[...] applications must always expect that read() / write() functions might read/write less bytes than requested; [...] tar is currently expecting safe_read() to always return the exact same amount of bytes as requested by tar:
https://github.com/Distrotech/tar/blob/273975bec1ff7d591d7ab8a63c08a02a285ffad3/src/create.c#L1058"

This is probably due to the somewhat misleading documentation of safe_read, which describes it as "Read up to COUNT bytes at BUF from descriptor FD, retrying if interrupted.". The word "interrupted" may be interpreted to apply to the case when not the full amount of data was read but in reality the implementation only deals with EINTR as can be seen here: https://git.savannah.gnu.org/cgit/coreutils.git/plain/lib/safe-read.c?id=b388203a65251b73dba040148039914062685c88 or https://github.com/coreutils/gnulib/blob/master/lib/safe-read.c (I'm not sure which one is the authentic source, but both seem to do the same thing. The first one is easier to read as the latter one defines macros to reuse the same function definition for both read and write.)

As a result of this, when using tar on the 9p filesystem (which has a very small block size by default), one gets errors like this:

user@vm:~/shared $ tar cf /tmp/test.tar register.h
tar: register.h: File shrank by 7721 bytes; padding with zeros
user@vm:~/shared $ tar cf /tmp/test.tar -W register.h
tar: register.h: File shrank by 7721 bytes; padding with zeros
register.h: Could only read 4096 of 9728 bytes

user@vm:~/shared $ tar xf /tmp/test.tar -O register.h | hd | tail
00000f90  62 6c 65 20 69 74 65 6d  73 20 61 6e 20 61 6c 74  |ble items an alt|
00000fa0  65 72 6e 61 74 65 20 62  61 63 6b 67 72 6f 75 6e  |ernate backgroun|
00000fb0  64 20 63 6f 6c 6f 72 0a  20 20 20 20 2a 2f 0a 20  |d color.    */. |
00000fc0  20 20 20 76 6f 69 64 20  75 70 64 61 74 65 41 6c  |   void updateAl|
00000fd0  74 65 72 6e 61 74 65 28  29 20 63 6f 6e 73 74 3b  |ternate() const;|
00000fe0  0a 0a 20 20 20 20 2f 2a  2a 0a 20 20 20 20 2a 20  |..    /**.    * |
00000ff0  6d 61 6b 65 20 73 75 72  65 2c 20 77 65 20 6f 6e  |make sure, we on|
00001000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00002e29

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by gray (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-02-11 gray Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code