Windows is Kicking My Ass Again

Ok, here’s the deal: we have dozens of printers, dozens of locations where computers are used, and hundreds of computers. Computers that are deployed to a given location get their own pre-set list of configured printers. And this list should be consistent, accurate, and sensible for all computers deployed to each location. So in order to handle this complexity, we built a cute little web app that distributes a zipped-up Platypus app that runs a script to set up a computer’s printers. To use it, you simply go to a web page, select your location from a series of three drop-down menus (building, floor, and room) and download a custom-built application that will issue the CUPS commands to configure the printers you’ve chosen. Neat, eh?

This setup was working fine until today, when we migrated the web app from our old web server to our new web server. Both the old server and the new server are running W2K, IIS, and Apache. They have all the same helper apps, etc. However, as of the migration, our freshly downloaded Platypus apps won’t run anymore. For some reason, the UNIX permissions—and the executable bit, in particular—aren’t getting preserved by the zip utility. (The application, being a .app bundle, needs to be zipped or tarred or something in order to be downloaded via the client’s browser.) Actually, the bigger question is why the permissions were being preserved by the zip utility on the old machine, since that wasn’t the expected behavior on a Windows box. But since the downloaded apps worked like we’d hoped, we weren’t too interested in rocking the boat. In order to preserve the permissions in the downloaded app, I tried using a bunch of different command-line zip tools, bsdtar, and all sorts of different flags, but had no luck whatsoever.

So, now that I’ve mulled over the problem a bit, I think I’ve hit on the solution. Instead of zipping or tarring the application stub on the server, I’m uploading a pre-built tarball to the server. This way, the internal permissions are still intact. Then, to get the customizations into the tarball, the server will append a few changed files to the pre-built tarball. Plus, instead of inserting commands directly into the script at the heart of the Platypus app (as I was doing before), that script now just sources a text file that contain the actual commands. I’ll give this setup a whack, but I think it will work properly.

Of course, all my prototyping for this custom-built application delivery system was done on Macs and Linux, so the script’s permission were preserved. But since our production machine is Windows, that most critical part of the program is totally (and apparently irreparably) horked. Ugh.

Update 8/29
Go figure, the new idea worked. Ok, so there were some difficulties to work through related to the different behavior of tar on my Mac and bsdtar on the Windows server, but once I got through those, it’s been working great. So remember kiddies: you can distribute custom OS X application bundles via the web by merging a pre-built tarball with your own custom additions (provided that their permissions don’t matter).

On OS X, this looked like “tar -rf ”. On Windows it looked something like “bsdtar.exe -cf @”. But the end result is the same: a tarball with intact permissions and custom components ready to be delivered to the browser.

Your Comment