Guard against too long filenames on eCryptFS. #2217
Conversation
The `AtomicDirectory` mechanism inflates the target directory file name length. In the case of unlocked operation in particular, this can lead to file name length violations when the PEX_ROOT is the default `~/.pex` and the home dir is encrypted with eCryptFS, which generally limits file name lengths to 143 characters. Guard against this explicitly. Fixes pex-tool#2087
|
@konstin if you have time to try installing Pex from "pex @ git+https://github.com/jsirois/pex@1e8182997a0633cc229ed926104ca8f2330a6730" to test this out under your eCryptFS home dir, I'd be grateful. |
There was a problem hiding this comment.
Ah, nice approach 👍
Is it worth preserving a little more context than just the hash, so that someone introspecting/debugging can match directories up more easily? I imagine this would be useful only very rarely though, so might not be worth the effort.
For example pycryptodome-3.16.0-overlongABC123... would at least hint that the directory in question is associated with some work about pycryptodome, if there's a crash or some error including that path. (The rule there being the first 20 characters of the original base name plus a label string that can be grepped-for in the PEX codebase (overlong in this example), but no particular attachment to that in particular).
|
Yeah, I think not worth the effort. This is an unusual case, and you'd have to have some very specific debugging needs on top of that unusual case for this to matter. |
|
I agree this won't actually ever happen, but there is also ~0 effort involved. |
The
AtomicDirectorymechanism inflates the target directory file namelength when deriving a work directory name. In the case of unlocked
operation in particular, this can lead to file name length violations
when the PEX_ROOT is the default
~/.pexand the home dir is encryptedwith eCryptFS, which generally limits file name lengths to 143
characters. Guard against this explicitly.
Fixes #2087