New version of file with very long name cannot be uploaded
OpenPublic

Description

Author: folengo

Description:
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: wikibugs-l.
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

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.