fileapi: generates crazy long filenames containing complete path of original files
cmake generates a directory .cmake
in the build dir. The content of <build_dir>/.cmake/api/v1/reply*
is generated from complete path of original files (adding even more stuff).
A pseudo-example :
- a
<src_dir>/the/path/to/something/...
- will produce a file
<build_dir>/.cmake/api/v1/reply/directory-the.path.to.something-<buildtype>-<hash>.json
Linux has a maximum filename length of 255 characters for most filesystems (including EXT4), and a maximum path of 4096 characters.
So a valid path longer than 255 characters for a directory in src_dir would generate a too long filename in .cmake/api/v1/reply
.
It is even worse for encrypted space. For instance eCryptfs uses more bits to encode path.
If filenames are encrypted, [...] eCryptfs prepends a bit of data on the front of the encrypted filename [...]. Empirically, we have found that character filenames longer than 143 characters start requiring >255 characters to encrypt. So we (as eCryptfs upstream developers) typically recommend you limit your filenames to ~140 characters.
The limitation of ~140 characters is easily exceeded in <build_dir>/.cmake/api/v1/reply*
.
It does not seem a strong limitation, but rather a bad design as it moves the limits of 4096 chars for a total path to the length limitation of a single file (255). Why not use real path with directories in .cmake/api/v1/reply
?