Page MenuHomePhabricator

New version of file with very long name cannot be uploaded
Open, MediumPublic


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



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:50 PM
bzimport set Reference to bz30202.
bzimport added a subscriber: Unknown Object (MLST).
  • 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.)

Bryan.TongMinh wrote:

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

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.