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)? > 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
signature.asc
Description: PGP signature
