test_tarfile fails in MacPython-OS9. The problem seems to be pathname-related, and I'm not sure whether the problem is with the test or with the tarfile module itself.

Various of the tests (test_seek, test_readlines) expect to find a file called, for example, "0-REGTYPE-TEXT", while the archive holds a file "/0-REGTYPE-TEXT". Apparently the tarfile module has some support for os.sep being different than "/", but not enough.

An added problem (or maybe the only problem?) may be that on the mac there are no files at the "root", only directories (disks, actually). So while "/tmp" is representable as "tmp:" this doesn't really work for files as they would be interpreted as directories.

Logged In: YES 
user_id=33168

Jack, I don't really know how to fix these.  My guess is
that doing something like os.path.normpath or abspath on the
names would help.  The code in test_seek and test_readlines
does this:

  file(os.path.join(dirname(), filename), "r")

Could that be changed to:

  file(os.path.normpath(os.path.join(dirname(), filename)), "r")

Perhaps, there should be a utility function to get the
normalized name?  I can try to make the changes, but can't
build or test on MacOS 9.  If you can suggest some changes,
I can make a patch for you to try.

Logged In: YES 
user_id=45365

The problem turns out to be deeper: the way tarfile handles pathnames needs work (and probably a lot of it). There is an assumption all over the code that you can convert unix pathnames to native pathnames by simply substitution / with os.path.sep. This will not fly for the Mac: /unix/path/name -> unix:path:name and relative/unix/path -> :relative:unix:path.

I've rigger tarfile.py to raise ImportError on the mac, changed the summary of this bug and left it open/unassigned with a lower priority. Maybe someone finds the time to fix it, some time.

Logged In: YES 
user_id=11375

Given that MacOS 9 support is gone, I'll close this bug.