Python: Extracting a file from a zip file with a different name

When dealing with zip files, sometimes you may want to alter the filename before extraction. Whether it is to run the name through some kind of sanitization routine or adjust it in some other way, the docs don’t seem to offer a clear way to do this. Instead, I’ve found the following works quite nicely:

import zipfile
 
zipdata = zipfile.ZipFile('somefile.zip')
zipinfos = zipdata.infolist()
 
for zipinfo in zipinfos:
    zipinfo.filename = do_something_to(zipinfo.filename)
    zipdata.extract(zipinfo)

The Python zipfile module provides the ability to reference the contents of a zip file via ZipInfo objects. These are tied to individual archive entries, but not by filename. During extraction, you can pass either an archive filename, or a ZipInfo object. If you alter the ZipInfo object’s filename attribute before extraction, extract(zipinfo) will then use the new name for extraction, but extract the original data.

Fixing e1000g Network Glitches in Solaris by Upgrading to the Latest Dev Version

In my last post, I discussed building my home file server around OpenSolaris and ZFS. ZFS is trivial to setup, and after building it, I started moving over all my data from my external 1TB drive on my old computer. I got excited, and wanted to test the performance of the disks and the network, so while copying data I NFS mounted the new server from one of my other machines and tried to copy data off it as fast as possible. Much to my dismay, network access on the machine promptly became sluggish and stopped working and I was left quite ticked off at having built this powerful file server only to have it be unable to serve files properly.

I did some quick Googling, and found this defect at OpenSolaris.org, which links to this underlying bug. The fix is either to upgrade Solaris to build nv_103 or newer, or as a workaround, add this to /kernel/drv/e1000g.conf:

tx_hcksum_enable=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0;
lso_enable=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0;

Then do “update_drv e1000g”, unplumb, and replumb the interfaces or reboot.  Unfortunately, I also discovered there are A LOT of bugs related to the e1000g, so I decided to upgrade a more recent kernel with all the fixes integrated.  Checking the system, I found kernel rev snv_101 is installed:

.oO(st0w@st0wlaris ~) uname -a
SunOS st0wlaris 5.11 snv_101a i86pc i386 i86pc Solaris

So the first I tried was to update OpenSolaris and hopefully that would give me kernel 103 or higher. Updating Solaris is trivially easy, only requiring the following commands:

.oO(st0w@st0wlaris ~) pfexec pkg refresh
.oO(st0w@st0wlaris ~) pfexec pkg image-update

And that’s literally it, just reboot after it completes and you’re done. One of the cool things about Solaris/pkg/ZFS is the concept of boot environments. Because ZFS supports snapshots, it upgrades the system using something like a snapshot of your current system (although it’s not technically a snapshot). It then upgrades the new revision, creating a boot environment (BE). After the image-update completes, you can view the BEs on your system as follows:

.oO(st0w@st0wlaris ~) beadm list
 
BE            Active Active on Mountpoint Space
Name                 reboot               Used
----          ------ --------- ---------- -----
opensolaris   yes    no        legacy     57.5K
opensolaris-1 no     yes       -          2.59G

Here you can see the opensolaris-1 BE that’s been created and will be active upon the next reboot. OpenSolaris.org has more documentation on BEs, and it’s worth reading. They’re pretty damn cool. Unfortunately upon rebooting, the kernel rev was the same. You can actually verify the packages that will be installed by pkg as follows:

.oO(st0w@st0wlaris ~) pfexec pkg refresh
.oO(st0w@st0wlaris ~) pfexec pkg image-update -nv

Had I done that before, I would have seen that there wasn’t an update to the kernel available. Live and learn. I then discovered that the preview of OpenSolaris 2009.06 is available, and based on snv_111a. You can upgrade from OpenSolaris 2008.11 to the preview of 2009.06 fairly easily. Just change pkg’s origin repository to the developer repository, image-update, reboot, and you’re done.

.oO(st0w@st0wlaris ~) pfexec pkg set-authority -O http://pkg.opensolaris.org/dev/ opensolaris.org
.oO(st0w@st0wlaris ~) pfexec pkg refresh
.oO(st0w@st0wlaris ~) pfexec pkg image-update
.oO(st0w@st0wlaris ~) pfexec reboot

Really. That’s it. It will create a new BE for you and upgrade that to OpenSolaris 2009.06, which is based on snv_111a. I can confirm that it does fix the network issues. Once OpenSolaris 2009.06 becomes an official release, you can just change your repository back to the release:

.oO(st0w@st0wlaris ~) pfexec pkg set-authority -O http://pkg.opensolaris.org/ opensolaris.org
.oO(st0w@st0wlaris ~) pfexec pkg refresh

UPDATE: Note that as per the release of OpenSolaris 2009.06, which has recently occurred, the syntax for the above command has changed slightly. Before being able to do any updates, you will need to issue the following instead, if you are staying on the dev path:

.oO(st0w@st0wlaris ~) pfexec pkg set-publisher -O http://pkg.opensolaris.org/dev opensolaris.org
.oO(st0w@st0wlaris ~) pfexec pkg refresh
.oO(st0w@st0wlaris ~) pfexec pkg image-update

You’ll probably get a note that you have to update pkg, so go ahead and follow the instructions, then repeat the image-update command.

If you want to switch to the production-grade release path, use the following commands and you’ll be all set:

.oO(st0w@st0wlaris ~) pfexec pkg set-publisher -O http://pkg.opensolaris.org/ opensolaris.org
.oO(st0w@st0wlaris ~) pfexec pkg refresh
.oO(st0w@st0wlaris ~) pfexec pkg image-update

But if you stay at the dev repository, you’ll continue to get new releases as they’re put live, roughly every two weeks. Dev releases can be buggy, so unless you have a reason to upgrade to dev releases, like a broken network driver or software that’s not in the mainline repository, it’s probably best to switch back to the release repository.