🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

2 total messages Started by Jordan K Hubbard Wed, 29 Jul 1992 22:41
GNU tar 1.10 truly loses on long filename remapping misfeature.
#273
Author: Jordan K Hubbard
Date: Wed, 29 Jul 1992 22:41
15 lines
1136 bytes
This has been a longstanding gripe but it took a couple of extra
cups of coffee before I felt steamed enough to comment on it. :-)

GNU tar (and, for that matter, most other tars I suppose) has a path
name length limitation that generally only shows up on very long
file/path names.  When this happens, GNU tar tries to be cute and
truncates the name to a "MaNgLeD" form that it later tries to rename()
after the tar has completed using a mapping file of sorts.  This fails
in the case where one is unpacking files on more than one filesystem,
such as in a complete system restore, since rename() cannot span
filesystems for obvious reasons.

I'd say the severity of this one is pretty high.

					Jordan
GNU tar 1.10 truly loses on long filename remapping misfeature.
#181
Author: Michael I Bushnell
Date: Fri, 31 Jul 1992 12:20
48 lines
2617 bytes
   Resent-Date: 29 Jul 92 18:41:50
   Newsgroups: gnu.utils.bug
   Path: lotus!jkh
   From: lotus!sparc3!jkh@uunet.uu.net (Jordan K Hubbard)
   Sender: gnulists@ai.mit.edu
   Date: 29 Jul 92 18:41:50
   Apparently-To: uunet!gnu-utils-bug
   Resent-From: bug-gnu-utils-request@prep.ai.mit.edu

   This has been a longstanding gripe but it took a couple of extra
   cups of coffee before I felt steamed enough to comment on it. :-)

   GNU tar (and, for that matter, most other tars I suppose) has a path
   name length limitation that generally only shows up on very long
   file/path names.  When this happens, GNU tar tries to be cute and
   truncates the name to a "MaNgLeD" form that it later tries to rename()
   after the tar has completed using a mapping file of sorts.  This fails
   in the case where one is unpacking files on more than one filesystem,
   such as in a complete system restore, since rename() cannot span
   filesystems for obvious reasons.

Ah!  I wish someone had brought this up sooner.  The mapping file
works fine, but it hadn't occurred to me that rename would cause a
problem in this way.

There are generally three possible solutions:

1) Use the distributed backup scripts.  These never dump more than one
filesystem per archive, and avoid the problem.  Since there are other
subtleties involved in backups that casual users are likely to miss,
using the backup scripts is a generally good idea.

2) When restoring a mangled name, put it in the right directory under
the wrong name; then rename will work.

3) If rename fails, attempt a more expensive copy to move the file
into place.

Using (1) is a work around.  Doing (2) is significantly harder than
(3), and is slightly less general, but (3) is potentially much slower.

I would like input about whether people would like solution (2) or
solution (3).  If you have an even better suggestion, that would be
welcome also.  Send mail to tar-mangle-poll@gnu.ai.mit.edu expressing
your preference.  (The Reply-To: of this message is also directed
there.)

	-mib
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads