Last modified: 2014-02-12 23:35:37 UTC
After succesfully uploading on Wikimedia Commons a 36 KB low resolution picture as a test, I tried to upload an update with the full resolution 17 MB version under the same file name. But I experienced the following error message : Could not rename file "public/4/43/A_design_to_represent_the_beginning_and_completion_of_an_American_settlement_or_farm_-_Dessein_qui_represente_la_maniere_d'etablir_et_de_parachever_une_habitation_ou_ferme_Americaine,_by_P_Sandby,_from_a_design_by_Gov_Pownal,_engraved_by_J_Peake.jpg" to "public/archive/4/43/20110803152543!A_design_to_represent_the_beginning_and_completion_of_an_American_settlement_or_farm_-_Dessein_qui_represente_la_maniere_d'etablir_et_de_parachever_une_habitation_ou_ferme_Americaine,_by_P_Sandby,_from_a_design_by_Gov_Pownal,_engraved_by_J_Peake.jpg". I tried a second time again and had Could not rename file "public/4/43/A_design_to_represent_the_beginning_and_completion_of_an_American_settlement_or_farm_-_Dessein_qui_represente_la_maniere_d'etablir_et_de_parachever_une_habitation_ou_ferme_Americaine,_by_P_Sandby,_from_a_design_by_Gov_Pownal,_engraved_by_J_Peake.jpg" to "public/archive/4/43/20110803154514!A_design_to_represent_the_beginning_and_completion_of_an_American_settlement_or_farm_-_Dessein_qui_represente_la_maniere_d'etablir_et_de_parachever_une_habitation_ou_ferme_Americaine,_by_P_Sandby,_from_a_design_by_Gov_Pownal,_engraved_by_J_Peake.jpg". I finally decided to upload the high resolution version under a different name. I wonder if the problem might not be that the new file name length, with the extra "20110803152543!" part is exceeding the maximum filename length 256 B limit.
*** Bug 30203 has been marked as a duplicate of this bug. ***
Indeed! Looks like the max file name length on ext2 family and ZFS is 255 chars; unsure whether NFS enforces the same. oi_archive_name entry will also be cut off at 255 chars, so it'd still be unusable. Finally switching the image/oldimage system to a modern space with content-based hashes as internal IDs and low-level filenames would help with this by eliminating the need to create and use such filenames based on user input... can't find a good BZ entry to hit though. (Bug 1780 has similar issues related to encoding -- it got marked as "fixed" despite not being fixed, have reopened it. Bug 363 proposes actual file storage in DB blobs which is unnecessary. Hash-based storage got implemented years ago for deleted files, but the interface for it for some reason didn't get extended fully with the Image->File refactoring that happened afterwards.)
Restricting the file name to 240 bytes should resolve this, until somebody implements the hash based storage.
Done the 240 bytes thing in r98430. Legacy long files are not affected by this; they should be moved manually. That reminds me, this restriction should also be enforced in Title::isValidMoveOperation. Leaving this bug open for that.
