A problem with MAXPATHLEN on a back

[Jilles Tjoelker]

On Sun, Feb 26, 2012 at 02:40:09PM +0100, Willem Jan Withagen wrote:
> I'm running into this on a backup-backupserver.
> (8.2-STABLE #134: Wed Feb  1 15:05:59 CET 2012 amd64)

> Haven't checked which paths are too long.
> But is there any "easy" way out? Like making MAXPATHLEN 2048 and
> rebuilding locate.
> Or is that going to propagate and major impact all and everything.

> Rebuilding locate database:
> locate: integer out of +-MAXPATHLEN (1024): 1031
> locate: integer out of +-MAXPATHLEN (1024): 1031

It should be possible to replace (sed -i) MAXPATHLEN with something else
in the locate source and recompile it. Changing the value of MAXPATHLEN
itself is not safe because it defines the size of various buffers in the
ABI (such as the one passed to realpath() if its resolved_path parameter
is not NULL); in any case, it is a very intrusive change.

Locate uses find(1) to generate its list of files, and find's output is
not subject to MAXPATHLEN (unless the -L option or the -follow primary
is used). Almost any use of the very long pathnames will require a
manual split-up though (cd'ing to an initial part shorter than
MAXPATHLEN, then repeating the process with relative pathnames until the
remaining part is shorter than MAXPATHLEN).

-- 
Jilles Tjoelker