Uploading an Image with the Same Filename Saves the Duplicate with an Appellation to Beginning of Filename #1314

Closed
opened 2026-02-05 00:34:34 +03:00 by OVERLORD · 1 comment
Owner

Originally created by @ruhrohshingo on GitHub (Aug 26, 2019).

Describe the bug

When you upload an image to Bookstack and the filename and extension already exist, Bookstack will upload the image anyway but append a sequence of three characters to the beginning of the filename. The sequence seems to vary based on what's being re-uploaded.

Steps To Reproduce
Steps to reproduce the behavior:

  1. Upload any valid image to Bookstack. Refer to first screenshot.
  2. Upload the same image from the above step and observe no variety of warning of dupe upload is provided and the dupe file is uploaded with some additional characters appended to the beginning of the filename. Refer to second screenshot w/ orange highlighted image, which is the dupe.

Expected behavior

Upon collision of an existing image (filename and extension), the user should be prompted as to whether they want to upload a copy (using some well known format like filename - copy.extension or filename(1).extension, etc.). The preferable action here on "yes" is to create a clearly named copy of the file(name). Allowing overwriting in the event of such collisions will inevitably lead to someone deleting an image used elsewhere (hopefully NOT at the Book or wider scope) and become more than a mere nuisance.

The fact that images have different scopes might make the proper fix of this behavior more involved that it would otherwise be. At the very least, you wouldn't want the dupe to overwrite the existing, which could wipe out the usage scope and cause a bunch of broken images that wouldn't be easy to detect without walking everything. Though it may also not be particularly desirable to have the dupe image to inherent the same scope as the image it's colliding with.

Alternatives are welcome!

Screenshots
If applicable, add screenshots to help explain your problem.
original_img_uploaded
dupe_uploaded

Your Configuration (please complete the following information):

  • Exact BookStack Version (Found in settings): v0.26.2
  • PHP Version: 7.1.30-1.el7
  • Hosting Method (Nginx/Apache/Docker): Nginx 1.12.2-3

Additional context

Have only tested this with valid image files and nothing weird like expecting a favicon to work. Ditto on formats like svg. Have only tested with jpg and pngs to get the described behavior.

Let me know if there screenshots aren't decent enough fidelity and I'll get fresh ones if needed.

Originally created by @ruhrohshingo on GitHub (Aug 26, 2019). **Describe the bug** When you upload an image to Bookstack and the filename and extension already exist, Bookstack will upload the image anyway but append a sequence of three characters to the beginning of the filename. The sequence seems to vary based on what's being re-uploaded. **Steps To Reproduce** Steps to reproduce the behavior: 1. Upload any valid image to Bookstack. Refer to first screenshot. 2. Upload the same image from the above step and observe no variety of warning of dupe upload is provided and the dupe file is uploaded with some additional characters appended to the beginning of the filename. Refer to second screenshot w/ orange highlighted image, which is the dupe. **Expected behavior** Upon collision of an existing image (filename and extension), the user should be prompted as to whether they want to upload a copy (using some well known format like filename - copy.extension or filename(1).extension, etc.). The preferable action here on "yes" is to create a clearly named copy of the file(name). Allowing overwriting in the event of such collisions will inevitably lead to someone deleting an image used elsewhere (hopefully NOT at the Book or wider scope) and become more than a mere nuisance. The fact that images have different scopes might make the proper fix of this behavior more involved that it would otherwise be. At the very least, you wouldn't want the dupe to overwrite the existing, which could wipe out the usage scope and cause a bunch of broken images that wouldn't be easy to detect without walking everything. Though it may also not be particularly desirable to have the dupe image to inherent the same scope as the image it's colliding with. Alternatives are welcome! **Screenshots** If applicable, add screenshots to help explain your problem. <img width="601" alt="original_img_uploaded" src="https://user-images.githubusercontent.com/25270034/63707484-dca95080-c7e6-11e9-91b4-12af64fb40ca.png"> <img width="599" alt="dupe_uploaded" src="https://user-images.githubusercontent.com/25270034/63707495-dfa44100-c7e6-11e9-9814-e4c183837134.png"> **Your Configuration (please complete the following information):** - Exact BookStack Version (Found in settings): v0.26.2 - PHP Version: 7.1.30-1.el7 - Hosting Method (Nginx/Apache/Docker): Nginx 1.12.2-3 **Additional context** Have only tested this with valid image files and nothing weird like expecting a favicon to work. Ditto on formats like svg. Have only tested with jpg and pngs to get the described behavior. Let me know if there screenshots aren't decent enough fidelity and I'll get fresh ones if needed.
Author
Owner

@ssddanbrown commented on GitHub (Nov 24, 2021):

Thanks for raising this with detailed information but I wouldn't really consider this as a bug. This is intended behaviour, that files with duplicate names have random characters appended to prevent file-name duplicates. Changing the format can bring its own complexities, and introducing user prompts in this journey complicates what as already a secondary part of the interface. Due to this, and this there's been little other request to change the current behaviour, I'm going to close this off.

@ssddanbrown commented on GitHub (Nov 24, 2021): Thanks for raising this with detailed information but I wouldn't really consider this as a bug. This is intended behaviour, that files with duplicate names have random characters appended to prevent file-name duplicates. Changing the format can bring its own complexities, and introducing user prompts in this journey complicates what as already a secondary part of the interface. Due to this, and this there's been little other request to change the current behaviour, I'm going to close this off.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/BookStack#1314