After creating so much media files without any problem today it happens repeatedly that the system only creates files with unique filenames in the root directory of the media folder.
I always follow the same schema:
1. choose a file on my local PC
2. select an existing folder in the media folder
3. select the media type "document"
4. click <save>
What a surprise to see this -->
I immediately clicked cancel and retried a second time. But nothing happened.
I searched for the uploaded file with its unique filename in the root of the media folder and deleted it via FTP.
I restarted the procedure and obtained the same result.
Then I had a look on the changes in the last 7 days (sorted by recordname asc.)
I created five media objects with the same unique filename without touching the option button.
After deleting these media objects I hope that I will be able to create a normal filename in the correct folder.
Not more than one or two weeks ago I heard of this strange behavior from one of my users and didn't believe it.
I thought about an error of the user, switching on the option button for unique filenames by mistake.
I have to beg his pardon now. And I need an explication.
> After creating so much media files without any problem today it happens repeatedly that the system only creates files with unique filenames in the root directory of the media folder.
If you try to upload a file with the same name as an existing file, webtrees will generate a unique filename.
This is to prevent you from overwriting an existing file.
My desktop computer does the same thing. If I download two files called "photo.jpeg", the second one will be called "photo(1).jpeg".
So, I am guessing that you are uploading a file with the same name as an existing file.
The unique filename is actually a "digital fingerprint" of the file. Every file will have a different fingerprint.
Two copies of the same file will have the same fingerprint.
There is a known bug that if you upload a *third* copy of a file, it will generate a unique name, but be unable to overwrite.
Instead, it should simply use it. It has the same fingerprint, so is the same file.
BTW - you raised this bug(!)