Problem/Motivation
There is a weird quirk: First upload of a file fails if the file is registered in the the table {file_managed}
, even if it does not exist in the file system. Second attempt works.
Steps to reproduce
I am unable to reproduce this in a consistent manner. When I upload a file attachment to a node, it gets registered in the table {file_managed}
, when I return to the attachement, and press "Remove" and save the node, it sometimes gets removed from the file system, and the table {file_managed}
. However, sometimes it is not removed.
However, this is done by core. It has nothing to do with this module.
Supposed a file (original name "'blå Bær.png'
) is registered in the table {file_managed}
, correctly transliterated to "bla_baer.png
" and you try to upload the file as a file attachment to a node, you'll get this error:
The specified file blå Bær.png could not be uploaded.
The file public://2021-11/blå Bær.png already exists. Enter a unique file URI.
Inspecting the file directory using the CLI shows that it has been uploaded, but not transliterated.
Then try to upload the same file again. I now get:
Your upload has been renamed to blå Bær_0.png.
Note that the message does not show the correct transliterated name.
However inspecting the file directory using the CLI shows that the name has been correctly transliterated - its name is "bla_baer_0.png".
Proposed resolution
As noted above, the problem lies outside this module, and is caused by some quirk in core I am unable to reproduce consistently.
However, I think a mention of this quirk, and its cause in the README.md would help those that run into this quirk.
Comments
Comment #2
jwilson3Thanks for the report @gisle. This seems exceedingly odd!
The module code where files are named and placed is very short and sweet:
https://git.drupalcode.org/project/filename_transliteration/-/blob/1.0.x...
I have a lot going on with Drupal 9 upgrades this week, and so I wonder if you could step through with a debugger and see the process where the file naming issue is happening.
I saw your post on #3216907: How is this module different from transliterate_filenames ? as well and appreciate your feedback and any help you can provide debugging this.
Comment #3
DamienMcKennaCould it be a permissions problem?
Comment #4
gisleFound the root cause, which lies outside this module, and updated the issue summary.
Comment #5
jwilson3Wow. Such an annoying bug @Gisle I'm sure! So, thank you for continuing to look at this and update the issue summary with your findings. I'm glad the issue is not caused by this module, and that it might have brought to light a core issue. In that vein, I'm also wondering if this issue is also present with the core patches on #2492171: Provide options to sanitize filenames (transliterate, lowercase, replace whitespace, etc) (which make this module obsolete). It would be interesting for you to test that approach and if so, maybe we can rope this issue into #2492171 or move this issue to core.
Make sure to disable this module before testing with the patch on the core issue.
Comment #6
jwilson3If I'm reading you correctly @gisle, it seems this is something explicitly to do with the "Remove" button in Drupal core.
I'd be happy to point to a core issue outlining the problem in documentation, but for now, sending people to this issue where there isnt really any other path forward (aside from just adding to our docs) seems not so helpful.
Can you create a follow-up issue for core?
Comment #7
jwilson3I'm recategorizing this one from a Code Bug to a Documentation Task, and marking postponed until a core issue can be created.
Comment #8
jwilson3Closing this issue as outdated. This contrib module is now obsolete and superseded by the new "opt-in" filename sanitization functionality added to Drupal core in version 10.2. See Change Record #2972665: New filename sanitization settings during upload (via UI or REST), new sanitization Event, changes to FileUploadResource constructor for more information.