I deployed the site to its production bucket today, the first real sync of the rebuild. Before touching anything live I ran a dry run:
gsutil -m rsync -r -c -n dist gs://www.jhoox.com-c asks gsutil to compare files by checksum instead of by modification time, which
felt like the more careful choice for a first sync. It printed a warning, copied two
files, and then stopped:
WARNING: You have requested checksumming but your crcmod installation isn't
using the module's C extension, so checksumming will run very slowly.
module 'sys' has no attribute 'maxint'
CommandException: 1 files/objects could not be copied/removed.No stack trace, no file name, just that one line and a count. It did not fail on the first file, or on all of them. Two copied cleanly first, which is what made this feel like a code problem rather than a permissions or network one.
sys.maxint was Python 2. Python 3 replaced it with sys.maxsize back when 2 was still
the default, and nobody expects to trip over the difference in 2026. gsutil still can,
because the C extension for crcmod was not installed. Without it, checksumming falls
back to a slower pure-Python path, and that path is old enough to still reference the
Python 2 name. The warning at the top says exactly this, in different words, and I read
past it the first time because it looked like a performance notice, not a compatibility
one.
The fix I used was to drop -c. gsutil’s default comparison (size plus modification
time) was accurate enough for a fresh build going to a bucket I had already inventoried,
and the sync completed without touching Python’s integer internals at all. Installing
the C extension (pip install crcmod, or the platform package your distro ships) fixes
the slow path properly if checksumming is actually the point.
I have not tried this on an older Python where sys.maxint still exists, so I do not
know how far back the working range goes. I know 3.14.5 with gsutil 5.37 and boto 2.49.0
breaks, and that dropping one flag was enough.