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/
./
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/core2-64/
./
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/all/
./
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:
debhttp://example.org/very/very/long/path foo main
debhttp://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
