Issue 5151: extractall method for TarFile objects not setting owner:group on directories (original) (raw)

Issue5151

Created on 2009-02-04 16:43 by npatters, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (8)
msg81143 - (view)	Author: Nicholas Patterson (npatters)	Date: 2009-02-04 16:43
Used the TarFile object to create a bzip2 compressed tar file (seems to have worked fine). Then used the extractall method to restore the archive in a new location. All the files appear to have the same permissions and owner:group as before, but most of the directories ('state' is only exception) have different permissions and the owner:group are set to the UID that was running the script in this case root:root. Partial original location listing /opt/fallback> ls -l /opt/agilent/ipcore/02.01/config total 112 drwxrwxrwx 2 agilent agilent 4096 Feb 3 14:07 dist -rwxrwxrwx 1 agilent agilent 208 Feb 3 14:07 hostnameCache.xml -rwxrwxrwx 1 agilent agilent 1000 Feb 3 14:07 hostnamecache.xsd drwxr-xr-x 4 agilent agilent 4096 Feb 3 14:08 inuse -rwxrwxrwx 1 agilent agilent 4019 Feb 3 14:07 log4cxx.properties -rwxrwxrwx 1 agilent agilent 9437 Feb 3 14:07 log4cxx.xml_template drwxrwxrwx 3 agilent agilent 4096 Feb 3 14:07 mebs -rwxrwxrwx 1 agilent agilent 4283 Feb 3 14:07 protocol.xml -rwxrwxrwx 1 agilent agilent 8339 Feb 3 14:07 registry.ini drwxrwxrwx 2 agilent agilent 4096 Feb 3 14:07 state -rwxrwxrwx 1 agilent agilent 886 Feb 3 14:07 trunknamecache.xsd Partial new location listing /opt/fallback> ll config total 120 drwxr-xr-x 6 root root 4096 Feb 3 16:38 ./ drwxrwxr-x 8 agilent agilent 4096 Feb 3 16:38 ../ drwxr-xr-x 2 root root 4096 Feb 3 16:38 dist/ -rwxrwxrwx 1 agilent agilent 208 Feb 3 14:07 hostnameCache.xml* -rwxrwxrwx 1 agilent agilent 1000 Feb 3 14:07 hostnamecache.xsd* drwxr-xr-x 4 root root 4096 Feb 3 16:38 inuse/ -rwxrwxrwx 1 agilent agilent 4019 Feb 3 14:07 log4cxx.properties* -rwxrwxrwx 1 agilent agilent 9437 Feb 3 14:07 log4cxx.xml_template* drwxr-xr-x 3 root root 4096 Feb 3 16:38 mebs/ -rwxrwxrwx 1 agilent agilent 4283 Feb 3 14:07 protocol.xml* -rwxrwxrwx 1 agilent agilent 8339 Feb 3 14:07 registry.ini* drwxrwxrwx 2 agilent agilent 4096 Feb 3 14:07 state/
msg81152 - (view)	Author: Martin v. Löwis (loewis) *	Date: 2009-02-04 19:30
Does the problem exist in 2.6 still? If you can't determine that easily, can you please provide a reproducible test case (e.g. some tar(1) created tar file plus a Python script)
msg81159 - (view)	Author: Nicholas Patterson (npatters)	Date: 2009-02-04 20:45
Can't easily test 2.6, our current release is based on 2.5. See attached Python script and tar file. See notes in comments at end of script, two variables need to be set to match your test directory structure. Thanks for any help you can provide.
msg81161 - (view)	Author: Lars Gustäbel (lars.gustaebel) *	Date: 2009-02-04 20:51
This is probably a duplicate of , which was fixed in r59713, i.e. between 2.5.1 and 2.5.2. Are you by any chance using Python 2.5.1?
msg81162 - (view)	Author: Nicholas Patterson (npatters)	Date: 2009-02-04 20:54
Using 2.5.0 on SLES 10 servers and 2.5.1 on Solaris 10 servers. Have only tested SLES so far since that's our main platform.
msg81163 - (view)	Author: Lars Gustäbel (lars.gustaebel) *	Date: 2009-02-04 21:02
Could you try to do a test with the patch from ? It is rather trivial to apply.
msg81164 - (view)	Author: Nicholas Patterson (npatters)	Date: 2009-02-04 21:11
Yep that fixed it, sorry to have used up your time. Still a bit new to the search feature on the site, didn't notice the form defaulted to only searching on open bugs/issues.
msg81165 - (view)	Author: Lars Gustäbel (lars.gustaebel) *	Date: 2009-02-04 21:34
Never mind! Thank you anyway for your report.