The reason I've forwarded this to linux-scsi is that reading the
"other" tar format from a tape locks the scsi-tape subsystem, locks
the scsi-subsystem and with the right combination. (Trying to ls
a target scsi filesystem) will crash my 2.1.131 kernel.
I'm not 100% sure that this is the cause of the crashes, the tape drive
is back where it belongs now so I can't test further at this time.
Lets say I've found a smoking gun though :).
The problem should be repeatable if you dd the unixware format archive
to a tape and try reading it back with tar. I havn't been able to check this yet,
so testing with a "normal" tar file first would be wise.
(I've removed the test3 (gnu-tar) attachment) to cut down the size of this post.
I think it's fair to say that tar shouldn't be able to take out the entire scsi
sub-system
when reading from a tape.
The lock up was repeatable on 2.0.32 and 2.1.132 for me.
Peter
-----FW: Probable Tar bug.-----
Date: Fri, 11 Dec 1998 08:04:01 +1000 (EST)
From: Peter Waltenberg <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Probable Tar bug.
Attached are two tar'd files.
One generated by tar on Unixware and readable (correctly) on
Unixware, Solaris, and AD. When read by Gnu tar the file is extracted
to the current working directory. (Or worse).
The problem involves the handling of archives with members having
pathnames > 110? characters.
Both Gnu Tar and the "other" tar's use some sort of extended header
to handle these cases.
As far as I can tell Gnu-tars approach is the better since it also handles
the case of a single filename being > 110 ? characters correctly.
However what gnu-tar doesn't handle correctly is extracting files from
the "other" tar format. Instead of interpreting the path component correctly
it simply extracts the file into the current working directory.
At least, when unarchiving from a file it does that. On Linux (and this isn't
a gnu-tar problem ) it locks the SCSI subsystem if I try to untar
one of these archives from tape.
I'm interested (in a morbid sort of way) in the results of doing this on
other OS's as well.
Attached are samples of the archives concerned. I've cut and pasted
the headers below as it's the easiest way to pick the problem up.
It'd be nice if this were fixed, I'd even consider doing it myself if it's
considered to be worth fixing. However in either case a note should
be added to the distribution explaining the difference in handling
of long paths.
(Gnu tar being so easy to compile, this may be all thats needed).
Note: I personally consider the format Gnu-tar GENERATES as being
superior. However it should still unarchive the other format correctly.
BTW: Minor bug. The configure script doesn't detect that Unixware 7
has only a <sys/signal.h>.
Unixware tar header. (test2.tar)
abbr_general_i.tcl^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@0000444^@0000764^@0000144^@00000006125^@06137746320^@00356
44^@0^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ustar^@00devsrc^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ode^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@0016777^@0001401^@./proj/dcelite/src/DCE1.2.2/dce/src/test/funct
ional/directory/gds/ts/gdscp/lib/x500abbr/invalid/^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@# @OSF_COPYRIGHT@
Gnu tar on Unixware header. (test3.tar)
././@LongLink^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@ 0 ^@ 0 ^@ 0 ^@ 161 0
10563^@ L^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ustar ^@root^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@root^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@proj/dcelite/s
rc/DCE1.2.2/dce/src/test/functional/directory/gds/ts/gdscp/lib/x500abbr/invalid/
abbr_general_i.tcl^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
The files are part of OSF DCE1.2.2 and are publically available.
Thanks
Peter
----------------------------------
E-Mail: Peter Waltenberg <[EMAIL PROTECTED]>
Date: 11-Dec-98
Time: 08:04:01
This message was sent by XFMail
----------------------------------
--------------End of forwarded message-------------------------
----------------------------------
E-Mail: Peter Waltenberg <[EMAIL PROTECTED]>
Date: 11-Dec-98
Time: 08:26:03
This message was sent by XFMail
----------------------------------
test2.tar
