Dear s3cmd maintainer, I have successfully been able to reproduce this issue with a basic setup. I forked the current source on salsa and committed a working patch [0] based on the upstream fix [1].
User "jrtc27" #debian-mentors suggested I use the actual patch from [2] instead of my own. They are absolutely correct and I didn't think of that earlier unfortunately. I can create a pull request of [0] as is or I can correct my fork to use upstream's patch. Please let me know which way you prefer. Also please let me know if there's anything else you want me to correct in changelog, patch etc. Hopefully my work here is of some help. If interested, here were the steps to reproduce the problem: 1. Create empty or use existing cache file i.e. ~/cache/s3.cache 2. Create a test folder with two random text files (i.e. ~/foo/file1.txt and ~/foo/file2.txt) 3. Create a test bucket i.e. $ python3 s3cmd mb s3://test.yourdomain.com 4. Put the files there with cache i.e. python3 3cmd put /home/dev/foo/*.* --cache-file=/home/dev/cache/s3.cache s3://test.yourdomain.com 5. Delete one of the text files (i.e. file2.txt) 6. Run the put command again I intentionally put python3 at the beginning of each s3cmd invocation as my system default is python2. Thanks for your time to read this. [0] https://salsa.debian.org/robysath-guest/s3cmd/-/commit/c9d628626dc35633ecf4e97ca38ad6dda334d0a4 [1] https://github.com/s3tools/s3cmd/commit/ee5e617c8787d39367f9b66aadee533bad346b43 [2] https://github.com/s3tools/s3cmd/commit/ee5e617c8787d39367f9b66aadee533bad346b43.patch Robinson
