New version of file with very long name cannot be uploaded


Author: folengo

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.

Version: unspecified
Severity: normal

bzimport added a project: MediaWiki-Uploading.Via ConduitNov 21 2014, 11:50 PM
bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz30202.
bzimport created this task.Via LegacyAug 3 2011, 4:54 PM
MarkAHershberger added a comment.Via ConduitAug 3 2011, 5:15 PM
  • Bug 30203 has been marked as a duplicate of this bug. ***
brion added a comment.Via ConduitAug 15 2011, 8:18 PM

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.)

bzimport added a comment.Via ConduitSep 29 2011, 6:43 PM

Bryan.TongMinh wrote:

Restricting the file name to 240 bytes should resolve this, until somebody implements the hash based storage.

bzimport added a comment.Via ConduitSep 29 2011, 7:03 PM

Bryan.TongMinh wrote:

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.

Gilles added a project: Multimedia.Via WebNov 24 2014, 3:42 PM
Jdforrester-WMF moved this task to Backlog on the Multimedia workboard.Via WebSep 4 2015, 6:32 PM
Restricted Application added subscribers: Steinsplitter, Matanya, Aklapper. · View Herald TranscriptVia HeraldSep 4 2015, 6:32 PM
jeremyb-phone added a subscriber: jeremyb.Via WebSun, Nov 8, 4:37 PM
jeremyb-phone set Security to None.

Add Comment