Apache OpenOffice (AOO) Bugzilla – Issue 54730
filenames (>255 chars) too long during installation
Last modified: 2006-07-07 09:42:24 UTC
When OOo is built with ALL languages, the installation scripts creates filenames longer than 255 characters, which are basically not supported on any filesystem, so installations breaks with errors like: ERROR: ERROR: Could not create directory: .../src680-m128/instsetoo_native/util/OpenOffice/install/en-US_af_ar_bn_be-BY_bg_ca_cs_cy_da_de_el_en-GB_eo_es_et_eu_fi_fr_ga_gl_gu-IN_he_hi-IN_hr_hu_it_ja_km_kn-IN_ko_lo_lt_ms_ne_nb_nl_nn_nr_ns_pa-IN_pl_pt_pt-BR_ru_rw_sk_sl_sh-YU_sr-CS_ss_st_sv_sw-TZ_ta-IN_th_tn_tr_ts_ve_vi_xh_zh-CN_zh-TW_zu_download_inprogress in function: create_directory or ERROR: Saved logfile: .../src680-m128/instsetoo_native/util/OpenOffice/logging/en-US_af_ar_bn_be-BY_bg_ca_cs_cy_da_de_el_en-GB_eo_es_et_eu_fi_fr_ga_gl_gu-IN_he_hi-IN_hr_hu_it_ja_km_kn-IN_ko_lo_lt_ms_ne_nb_nl_nn_nr_ns_pa-IN_pl_pt_pt-BR_ru_rw_sk_sl_sh-YU_sr-CS_ss_st_sv_sw-TZ_ta-IN_th_tn_tr_ts_ve_vi_xh_zh-CN_zh-TW_zu/log_SRC680__en-US_af_ar_bn_be-BY_bg_ca_cs_cy_da_de_el_en-GB_eo_es_et_eu_fi_fr_ga_gl_gu-IN_he_hi-IN_hr_hu_it_ja_km_kn-IN_ko_lo_lt_ms_ne_nb_nl_nn_nr_ns_pa-IN_pl_pt_pt-BR_ru_rw_sk_sl_sh-YU_sr-CS_ss_st_sv_sw-TZ_ta-IN_th_tn_tr_ts_ve_vi_xh_zh-CN_zh-TW_zu.log Solution: don't build filenames for installation using the appending of all the <languages>_<countries>, or let the user override this long names with some var.
As alternative I suggest to use instead of the string built using all the language names, its md5sum, like in this small shell script: #!/bin/sh LONG_FILENAME="en-US_af_ar_bn_be-BY_bg_ca_cs_cy_da_de_el_en-GB_eo_es_et_eu_fi_fr _ga_gl_gu-IN_he_hi-IN_hr_hu_it_ja_km_kn-IN_ko_lo_lt_ms_ne_nb_nl_nn_nr_ns_pa-IN_p l_pt_pt-BR_ru_rw_sk_sl_sh-YU_sr-CS_ss_st_sv_sw-TZ_ta-IN_th_tn_tr_ts_ve_vi_xh_zh- CN_zh-TW_zu" SHORTER_FILENAME=`echo $LONG_FILENAME | md5sum |cut -f1 -d" "` echo $SHORTER_FILENAME which gives: 1bacc6d05a040cae0afe7acacd279fc1 So we'll have: .../src680-m128/instsetoo_native/util/OpenOffice/install/1bacc6d05a040cae0afe7acacd279fc1_download_inprogress .../src680-m128/instsetoo_native/util/OpenOffice/logging/1bacc6d05a040cae0afe7acacd279fc1/log_SRC680__1bacc6d05a040cae0afe7acacd279fc1.log in this way the filename lenght will be of only 32 characters long (or 52 with the appende string _download_inprogress), but will be always the same, according to any number of language built, and the dependency on the language names will be also preserved. WDYT?
of @ mh: Please have a look.
I suggest to do a replace like "all_lang".
If you replace the string to "all_lang", it would work only when "all languages" are choosen, but one might chose a set of languages to build which is near to all languages (e.g. all languages but one), and would cause the string to be bigger than 255 chars anyway.
- I'm not the author of this code - this is not the default setup (configurations) ghibo: how did you started the build for all languages? Why do you want to have one instset with that many languages in it?
1) yes, with argument of config_office/configure's --with-lang=ALL or --with-lang='ar be...'. 2) Why there shouldn't be built all the languages (or most of) if they are included in the source? And anyway this is needed for multiple language package building. 3) It seems the problem is in the file solenv/bin/make_installer.pl, probably in the building of var $loggingdir as well as $languagestringref. Who wrote that code?
Well, I wrote the code. And I introduced this directory names, because they show the content of the directories and the log files. Nobody knows, what he can find in a directory or a file named "1bacc6d05a040cae0afe7acacd279fc1" If you build different installation sets with different languages this will not be a good solultion. Normally our installation sets do not have so many languages. I think this installation set will have a size of more than 1 GB.
I too think such big instset is a special case. What about something like this (meta-code): NAME="en-US_pt_..." if ( length($NAME) >150 ) NAME=md5sum($NAME) It is simple and the special case is solved too?
x is: yes, more or less you get 30MB (unpacked) more for each language (the main one for 1 language is around 360MB unpacked). Consider that later you split the whole installation into subpackages (one big for main [libraries+en_US], plus small subpackages of 10-12MB in size, one for each language to be added to the main one). Regarding your consideration about the naming, yes, the md5sum may appear ugly, but on the other hand the translation string is contained into the build set. Maybe you may the script a little more verbose printing on stdout both the string of languages and its md5sum so that would be more easy to find. Or even better you put a filename in the same place, called for instance "1bacc6d05a040cae0afe7acacd279fc1.dir" (.dir for dirs, and .file for files) which will contain the string of languages, maybe even in a more readable (and sorted) way: en_US af ar bn be-BY bg ca cs cy da instead of "en-US_af_ar_bn_be-BY_bg_ca_cs_cy_da_de_el_en-GB_..." The pjanik suggestion sound good, i.e. only use the md5sum replacement when the filename goes beyond a certain amount. 100-150 chars can be a good value too.
Created attachment 30789 [details] patch for bug 54730
changing type to PATCH
*** Issue 62224 has been marked as a duplicate of this issue. ***
Okay, I think this is a patch for 2.0.4 -> setting target.
Patch included into cws native51
IS -> OF: Created multilang installation set with short directory names -> please verify
OF: I can't see any regressions in this cws .
No regression in m175.