This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author srid
Recipients r.david.murray, srid
Date 2009-06-04.22:28:15
SpamBayes Score 3.9815976e-07
Marked as misclassified No
Message-id <1244154497.9.0.219226865054.issue6196@psf.upfronthosting.co.za>
In-reply-to
Content
[David] I don't see why the tarfile case should be different from the
tar case. (...)

As I explained, Viz:

[quote]'(...)the very reason to write a program to extract tarball
(instead of doing it manually) is to automate it .. which automation is
*more effective and simple* if ``extractall`` had a flag such as
readaccess=True'[endquote] (emphasis added)

[David] You can "always chmod it later" in python, too (with os.walk and
os.chmod). (...)

Of course, I can. Or:

        EXECUTE = 0100
        READ = 0400
        dir_perm = EXECUTE
        file_perm = EXECUTE | READ
        for tarinfo in f.getmembers():
            tarinfo.mode |= (dir_perm if tarinfo.isdir() else file_perm)

As you can see, for a tarfile with huge list of files.. this can be a
performance issue.

[David] (...) Perhaps the real need is for a recursive chmod in shutil?

The real need is to fix the weird permissions on some tarballs (such as
generator_tools-0.3.5.tar.gz in PyPI and the above mentioned pyopenssl
tarball).

This need usually leads to designing workarounds. 

I just think it is not simple (as in, keeping the code off from such
hacks that are tangential to the problem being solved) and effective (as
in, not having to deal with potential unintended side effects like bugs
in the post-fix chmoding or in the pre-fix tarinfo mode modifications).

Hence the feature request.
History
Date User Action Args
2009-06-04 22:28:19sridsetrecipients: + srid, r.david.murray
2009-06-04 22:28:17sridsetmessageid: <1244154497.9.0.219226865054.issue6196@psf.upfronthosting.co.za>
2009-06-04 22:28:16sridlinkissue6196 messages
2009-06-04 22:28:15sridcreate