Re-uploading a file doesn't work (BB-899)

Tarek Ziadé avatarTarek Ziadé created an issue

Hi,

thanks for bitbucket, it's a great service.

In my project I've noticed that removing then re-uploading the same file to update it in the download section doesn't work : the old file is still delivered.

It seems to be a cache issue. I ended up uploading the file under another name.

Regards Tarek

Comments (11)

  1. Joe Amenta
    • changed status to open

    I can confirm that this bug is still present as of today.

    Steps to reproduce:

    1. Navigate to a repository's downloads page (http://bitbucket.org/--ownername--/--reponame--/downloads/)
    2. Upload a file in the "Add Download" section. Wait for the upload to complete.
    3. Using some hashing algorithm, note the hash of the file you just uploaded.
    4. On that same page, delete that downloaded file using the red icon to the far right.
    5. Upload a different file with the same name. Wait for the upload to complete.
    6. Using the same hashing algorithm as in step 3, note the hash of the file you just uploaded.
    7. Download the recently-uploaded file from that same page.
    8. Using the same hashing algorithm as in steps 3 and 6, note the hash of the file you just downloaded.
    9. Compare all three hash values.

    Expected result:

    The hash value from step 8 matches with the hash value from step 6. The file being hosted on bitbucket is the same file as the file that was last uploaded.

    Actual result:

    The hash value from step 8 matches with the hash value from step 3. The file being hosted on bitbucket is the same file as the file that was first uploaded.

    Workarounds:

    Upload the new file under a different name.

    My thoughts:

    I like Tarek's suggestion: this is likely an issue with bitbucket keeping the old file around in cache, instead of deleting it when prompted to do so. Uploading a new file under the same name is simply turning on the serving of the old file from cache, regardless of the contents of the new file.

    This bit me today when uploading a "fixed" version of a "broken" tarball. I accidentally sent out a link to a file that I knew was "broken" instead of the "fixed" one!

  2. Jesper Nøhr

    It's not a caching issue, at least not on our end. We let you upload the files straight to CloudFront (Amazon CDN service), and they're unfortunately the ones caching it.

    There is a workaround that we can employ, but we haven't yet. Requires further investigation. Leaving the issue open for now.

    Sorry for the inconvenience this is causing you. :-(

  3. Brodie Rao

    OK, we've just put a fix for this that I think should solve the problem once and for all.

    We were incorrectly caching responses from the download view that redirects you to the CDN. We were caching for 30 minutes. We no longer cache on this view, so any changes you make should be reflected immediately.

  4. Log in to comment
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.