Thread View: gnu.utils.bug
2 messages
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.
Author: Jordan K Hubbard
Date: Wed, 29 Jul 1992 22:41
Date: Wed, 29 Jul 1992 22:41
15 lines
1136 bytes
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.
Author: Michael I Bushnell
Date: Fri, 31 Jul 1992 12:20
Date: Fri, 31 Jul 1992 12:20
48 lines
2617 bytes
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