failures on Windows buildbots, but it's hard to know how since the regrtest
failure output is useless here, and it never fails when a buildbot slave runs
test_tarfile the second time in verbose mode.
the file object in binary mode.
The Windows buildbot slaves shouldn't swap themselves to death
anymore. However, test_tarfile may still fail because of a
temp directory left behind from a previous failing run.
Windows buildbot owners may need to remove that directory
by hand.
Problem: if two files are assigned the same inode
number by the filesystem, the second one will be added
as a hardlink to the first, which means that the
content will be lost.
The patched code checks if the file's st_nlink is
greater 1. So only for files that actually have several
links pointing to them hardlinks will be created, which
is what GNU tar does.
Will backport.
code use proper functions to get paths.
Changed the name of tar file that is searched for to be absolute (i.e., not use
os.extsep) since filename is locked in based on name of file in CVS
(testtar.tar).
Closes bug #731403 .
and test_support.run_classtests() into run_unittest()
and use it wherever possible.
Also don't use "from test.test_support import ...", but
"from test import test_support" in a few spots.
From SF patch #662807.
- the test was sloppy about filenames: "0-REGTYPE-TEXT" was used where
the archive held "/0-REGTYPE-TEXT".
- tarfile extracts all files in binary mode, but the test expected to be able to
read and compare text files in text mode. Use universal text mode.
Lars Gustäbel
Georg Brandl
Neal Norwitz
Tim Peters
Martin v. Löwis
Andrew M. Kuchling
Brett Cannon
Walter Dörwald
Jack Jansen