|
On 6/18/24 18:50, David Kalnischkies
wrote:
On Tue, Jun 18, 2024 at 11:21:06AM +0800, Changqing Li wrote:When I run "apt-get install with a long path", the following error is reported: "Could not create temporary file for ...long_path..._Packages - mkstemp (36: File name too long)"Shouldn't that already be a problem with 'update'? Or are you talking about 'apt install /very/very/long/path/…' (or a --with-source variant)? You are right. Sorry, I wrote the wrong cmd. it is "apt-get update" failed. Is it possible for me to change the subject? Let me describe more detail: I am working on yocto project, and apt-get update is executed during create rootfs. and the source is like this: deb [trusted=yes]
file:/buildarea/cli/yocto/builds/yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0/oe-rootfs-repo/qemux86_64/
./
And before apt-get update, "apt-ftparchive packages . >
Packages, apt-ftparchive release . >> Release" is executed
to generate index file under above source path. Then apt-get update failed with error like: E: Failed to fetch store:/buildarea/cli/yocto/builds/yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0/oe-rootfs-repo/all/./Packages Could not create temporary file for /buildarea/cli/yocto/builds/yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto_yocto/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0/apt/lists/partial/_buildarea_cli_yocto_builds_yocto%5fyocto%5fyocto%5fyocto%5fyocto%5fyocto%5fyocto%5fyocto%5fyocto%5fyocto%5fyocto%5fyocto%5fyocto%5fyocto%5fyocto%5fyocto%5fyocto%5fyocto%5fyocto%5fyocto%5fyocto%5fyocto%5fyocto%5fyocto%5fyocto%5fyocto%5fyocto%5fyocto%5fyocto%5fyocto%5fyocto%5fyocto%5fyocto%5fyocto%5fyocto%5fyocto%5fyocto%5fyocto%5fyocto%5fyocto%5fyocto_tmp_work_qemux86%5f64-poky-linux_core-image-minimal_1.0_oe-rootfs-repo_all_._Packages - mkstemp (36: File name too long)
The suggest patch may not proper, I just want to say that the
original idea is cut the first few characters for the temp file. Eg: example.org_very_very_long_path_dists_foo_main_binary-amd64_Packages -> ry_very_long_path_dists_foo_main_binary-amd64_Packages
Thanks Changqing How about fix with the following patch?[…]Truncate it when it is longer than 240 (leave some spaces for ".Packages" and "._Release" suffix)Imagine as source: deb http://example.org/very/very/long/path foo main deb http://example.org/very/very/long/path bar main that would roughly translate to e.g.: example.org_very_very_long_path_dists_foo_main_binary-amd64_Packages example.org_very_very_long_path_dists_foo_main_binary-i386_Packages example.org_very_very_long_path_dists_bar_main_binary-amd64_Packages example.org_very_very_long_path_dists_bar_main_binary-i386_Packages So, you can't just arbitrarily cut from the end as that potentially maps multiple URIs to the same filename (and while I am not sure if that method is UTF-8 safe, truncating is definitively not). The suffix part in your description is also misleading. The "suffixes" you mention tend to be already part of the URI (and hence the filename), so you would cut them. "Suffixes" that might be attached tend to be on the short side like if a file is compressed (although nobody said that a compression algorithm needs to use e.g. 'xz', it could also be 'xtremely_zmall'. The longer ones like .diff/Index (or the individual patches) tend to use this method (and would again be subject to truncating) if I remember right (haven't checked). Julian entertained the idea of storing files by hash in lists/ – that would at least limit the problem to files we don't have hashes for, as in the (In|)Release(.gpg|) file(s) – and of course every repo we don't have hashes for. For these we could go with a (directory)index file that tells us about the mapping. Such an index might even be better than our current guessing what files could exist and checking for their existence in many compression formats, but that would probably amount to a micro-micro optimisation… Anyway, drawback is of course that changing filenames means everything that access the files directly is broken. We told everyone who wanted to listen that they can use 'apt-get indextargets' to access filenames, but I doubt everyone wanted to and some might even have "good" reason like not doing shell (heck, I do sometimes. Our tests do. …) On a sidenote, NAME_MAX seems as constant as PATH_MAX, as in on some filesystems it is larger (or potentially smaller), but [surprisingly] more in effect than PATH_MAX. In any case, no magic numbers please. Oh, and congratulations! I suppose that problem exists since the beginning (1997) and I haven't seen it being mentioned while I am around (~15 years), so that makes this some very old and esoteric problem. Best regards David Kalnischkies |