Zip issue after upgrade to SLES 11 SP2

SUSE Product Topics SLES Configure-Administer
1

I have a user-written perl script that archives files with an mtime > than x months from specified directories that is no longer working. There are a number of directories that are processed by the script. The problem started the day after I upgraded my servers from SLES 11 SP1 to SLES 11 SP2. I believe that I have tracked the problem down to the zip command not processing the files in the include list.

The script logs messages into its own log file and this file contains the following messages for each of the directories that contain data to be archived:
warning [/home/hlinke/DBReports/zi7EL3DY]: zipfile is empty
test of /home/hlinke/DBReports/DBReports_2012AUG.zip FAILED

zip error: Zip file invalid, could not spawn unzip, or wrong unzip (original files unmodified)

The perl command that is failing is
$cmdstat = system(“zip -mTrjq $archfile $dir -i\@$zi”);

I inserted print statements into the perl script to reveal the values of the symbolic variables used and found that ‘cmdstat’ is set to 2048. I built a command-line-interface zip command to test with based on the symbolic values and have been able to recreate the problem. The command that I am testing with is:
zip -Trjq /home/hlinke/DBReports/DBReports_2012AUG.zip /xs2files/DBReports -i@/home/hlinke/DBReports/DBReports_2012AUG_include.lst

Note that the command is running against production data so I removed the option to ‘move’ (i.e. delete) the source files after they are added to the archive and I also modified the file containing the include list to contain only one file.

I’ve tried all kinds of variations to the -i switch to no avail. I originally thought that maybe perl was upgraded as part of the SP2 upgrade but ruled out perl when I was able to recreate the problem via the CLI.

I am in a bind as the script hasn’t been archiving data for over 2 months now and the file system has grown from 78% to 96%. This filesystem does tend to grow this time of year due to the nature of the business so we didn’t think that a script was failing.

Any ideas as to what changed with the SP2 upgrade? What do I need to change with the zip command to get it working again? This script was written around 2005 and has been worked until the SP2 upgrade.

Harley

2

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In my own word I believe your problem is as follows:

The zip command did something in SLES 11 SP1, and now trying that same
something in SP2 fails. That something involves taking an input file of
files to be added to the created .zip file, and the .zip files
themselves are actually created but are empty (based on the error; it’d
be nice if you could confirm that though). As a result your backups are
not removing old files (which is good, because they’re not being backed
up) and your filesystem is running out of space.

How big are your include files, in number of lines? How big were they
four months ago (before the upgrade)? You probably know, but the ‘wc’
command can tell you this:

wc -l /home/hlinke/DBReports/DBReports_2012AUG_include.lst

Based on the following command:

zip -Trjq /home/hlinke/DBReports/DBReports_2012AUG.zip
/xs2files/DBReports

Doing some poking around the ‘zip’ command is kind of weird (to me) in
its need for that directory (/xs2files/DBReports) when it is about to
get a list of files to include explicitly. Oh well.

I see the same thing with zip 3.0 on openSUSE 12.2 x86_64, for what it’s
worth. Removing the ‘j’ option allows things to go through but that
does not remove the paths. I can also have it work by removing the ‘r’
option. It seems that the two are (now?) mutually exclusive, though I
do not know why that would be off the top of my head. I can confirm
this works for a SLES 11 SP1 system I found and it seems like version
3.0 of the zip command has this added, though nothing in the changelog
shows anything definitely related:

rpm -q --changelog zip

Anyway, my best advice is to either drop the ‘j’ option (is that
something you really want?), backrev the ‘zip’ package, or change backup
methods (tar/bzip2 for example). Either way this is probably worth
reporting a bug and the manpage talks about how to do that.

Good luck.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQfG/FAAoJEF+XTK08PnB5nloP/3rri+gqObhh4I9RYqh7Hu/Q
pqCLT5HMCAWe9TW68ZinXiosv3HNiaDhbYTiPcLeFO3HZ9+lNQCc7/esskOEa2M+
45qPtOxhCWrfouWvN7VVS3GZ4J/m9pFqWEpcF06Df8MfKFudCXbCL3lihRnXkZkJ
5tFWyoYDFj0eHWKa5WAB2+lQKcmXWm5QpCr8Q/8uPCSvO019a9bujrCh6lvDKdsQ
FFwfI216UB2la0TDOJzS94pesj4xJxFNhKN45lFMEO8IFuxkZ/f1iExm+Jv8SV9i
J2G9NBB2tGW2pew9eEp6bxZnofpYaAKr7KWqz+96p0d/F9V39zQ4gfRmAVSxU76i
WsrK59681ZepfCPxUlKYV90kDwMl8LIKCawb6xDKx5mZcbu8e023ly0tQ+pTjh8S
PwnZpoupNzQ2dM5LfvLTrFxqK7hRJ4Wd1kcHrIsdFQIekdUG0AMcKxnvM9pSZvrU
zXElB7CDw6wG0gpbqrMZ5fDsCloUdq/R+6Mw1CHrJOtpuWzI2S18c2zFMLw8nOKD
CA70NhpPi6Ssa7CvCItku1bQIXJPv+Acr9DsYs0MT7depnwHhWGIWrSjUSOh/sTb
8t0yHKTs/ZER4f836hvcHEEiDKuJOrzl8OzedVKreZATdsekHJnaw31O0ore3Mps
Scpm5z6VRwe+vJwvpXfn
=73l2
-----END PGP SIGNATURE-----

3

ab,

Thank you for confirming that my command works on SLES 11 SP1. I no longer have a SP1 system to test with. I was able to port my files and directory structures to a SLES 10 SP4 system and the zip command worked. I will open a bug regarding the zip command.

Harley

4

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

FWIW, I reported Bug# 785305 on the OpenSUSE 12.2 side of things so you
can refer to that when talking to support about the SLE side.

Good luck.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQfXF0AAoJEF+XTK08PnB52kAQAK5V/AeUyRdBD+ACz0ps07fp
G+vhoTdxgF4aBQhByPHEjahNoz35QyYGLwnjGpSReVlVj/Mwali44/w8FL+X0F2v
sXrXqTymcashrM7UO/c3ryaOd/p8MPG/zOgNh3hq/dohpxvRi5gxo+jQyY0ySNCT
5Fg95MVRIOalSJ/ygk2eaR1rU2zdPZCiz86Mxphb0gRdCOup0SPRoZkrF7WZKYf3
EROfs0w1r3LhPZKS3aAVImdzCAvnPass2IC5Aw1QtP1uqHI7iD4QCwXhO3s4gBeJ
sbNSihl5oEPJoG1ztgYWk9PgcTOVkRtsIqJPqoJ4GVl+ZKU73MoywO6YDaN3et6q
zF5POWWQhQAbtRopi20UJWxO+IAMd3yjQcSKBf0tvOwB1XWxyJW9g/EJUV3Z5yxo
xXZ79zhRyXAaCXs3X+db8tvg2wzrXkxJe5rM+4hjhWbnxeewErWnEmApXN2h73T1
FGMtpQ4bHltRbRv7+w2Sm6FTqG/1YNKPD2jR8900MLmbgPYEEMXO+PD1sG8IdcLw
ZlL4uvI1X7cjUlaQFoL58Ww9LoSj2ZBcmRbii0Ik09Ts6D5eXL+LLV1ZBnlQI3+4
+pLuL8JvmLZMCa7D+TczcXfP5i7LcCWMVNQ23MJNuOoEXg+54f/OxfYb9OZUQov2
4u4jlEAIEkQhpMrzx42P
=a7ob
-----END PGP SIGNATURE-----

5

Great news! One of my coworkers was assisting me with this issue and stumbled on a resolution. Note that I inherited this issue from someone who wrote the command in a script many years ago. I have no idea why he placed the include list at the end of the command.

If you have a zip command in the following format, the command will fail after upgrading to SLES 11 SP2. This format of the command works prior to SLES 11 SP2.
zip -mTrjq archive_name archive_dir -i@include_list

If you move “-i@include_list” immediately after the command name the command works on SLES 11 SP2.
zip -i@include_list -mTrjq archive_name archive_dir

Harley

6

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Well that’s interesting, and a little ironic to me because of the
manpage comments on the -i option:

Though the command syntax used to require -i at the end of the command line, this version actually allows -i (or --include) anywhere. The list of files terminates at the next argument starting with -, the end of the command line, or the list terminator @ (an argument that is just @). So the above can be given as

Still, great find. Should make this that much easier for the devs to
fix since now order seems to matter, and of course it gets you on your
way too which is the most important thing.

Thanks for posting back.

Good luck.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQfsqyAAoJEF+XTK08PnB5ACMQAKt241sI2Ml383R0mD7z/7TD
aj6cAMwHT3EGBF7NVnq/ZYCLJIq+jE++fr98MW8CLn2ptKnrseSUkAZwRak7gs4R
KWwZJH1VdQHM1s0VtJkoDx1xkUO+q2yW67U1unGR0BLCrmGEpEiQdZPOc4cNgn9k
nZJP8yw9/HNGvfbRWVZjRKkpg9Iyr7K/ZAAEvqfVJki5knPBjhqc8usu+SBDqJnK
mY1kMsRidbX5uVogADpx24anQG/phwBkxkgL0B3mxXPrhVArv8qcP54e7u2fbw28
8YHslWx48tuKEs6S2E4KsF4ZriZmcxlJgPM1qKIrhqlER+wJGxnORmKaIFDAtsQI
tyFyk32Gra03ES/8JBknS1C22Hah5wuSjab8kn1FfxgaGuQPLiPREs9SMIki9Agd
rIkEDFgGACNxVi+dK2iPwmRkP7+UhST6NGq8b7tTTEZ95RmSuDg6pTLiLicpPsLY
89yflM3rQ+7LA+XkkkGg+aYGoiDKG7Bd737KH0Rqso/rwkcxZ0IfAdWX8aPeiqlp
S304y2juyZijbvfexA/kC7jxi0fLokDhOiwBL+2iNoDRl+dw6DespBP9ri8MoKSG
0dq0axD9edgmu9JnGnTw/Mtanyu5A/8G4/bFHlAfXWzzeJiTCSQp4xml/4cixKIC
feMOCCgr7CqF2P0kBMja
=LQhe
-----END PGP SIGNATURE-----