Date: Sat, 3 Mar 2012 17:37:27 +0100 From: Jilles Tjoelker <jilles@stack.nl> To: Willem Jan Withagen <wjw@digiware.nl> Cc: "stable@freebsd.org" <stable@freebsd.org> Subject: Re: A problem with MAXPATHLEN on a back Message-ID: <20120303163726.GA21464@stack.nl> In-Reply-To: <4F4A3639.2080408@digiware.nl> References: <201202250747.q1P7ldaJ005410@zfs.digiware.nl> <4F4A3639.2080408@digiware.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120303163726.GA21464>