allowing amazon applying buttons cache cached cases check copy development download due file files happy identical issue issues links minutes move names needed normally open over perhaps problem process product products purchased resolve server side site solution source tested testing uploaded wanted won

Hey guys!

I was doing some testing and found an issue. I wanted to check to see if this was a known problem or if anyone else had experienced this?

I had uploaded a bunch of .zip files to Amazon S3 and created products here on E-Junkie.

I wasn't happy with the naming convention and organization on the Amazon side, so I re-arranged and restructured my folders and renamed the .zip files.

I plugged in the new download links to the product, and created new "Download" buttons for my test site.

However, any of the products I purchased and tested were giving me corrupted .zip files. The file names and size were identical to the stuff on the Amazon side, and it was still allowing me to download them, but I could not open the files without 100% corruption issues.

I'm currently in the process of re-uploading and rebuilding the product base, and so far 4/4 have worked perfectly, but obviously concerned about what might happen if I needed to move files again in the future?

I'm just curious if anyone has any issue with renaming stuff on the Amazon S3 side and seen any issues with their products after the fact. Once I get everything uploaded and packaged this time around, you can bet I won't be changing my mind again anytime soon!

I've asked Development about this, and they've seen instances like this on rare occasion before; they think it may be due to some obscure glitch in our logic that determines whether we already have a copy of the product's remote file cached at our end -- e.g., in these rare cases, we might be serving a file from our cache while we're actually still in the midst of caching a copy of that file from its remote source, so the file that gets served is incomplete. The issue may resolve itself once the caching is actually complete, which should normally happen within 15 minutes of the first download of a new remote file; meanwhile, Development is continuing to investigate the issue towards applying a more ironclad solution.

Good to know! I will admit that I was testing the new links not long after I had moved them over. The more I thought about it, the more I thought that perhaps there was a server delay in "catching up". If I need to do another renaming or moving of files, I'll be sure to give it a little more time before testing.

Thanks for the response!