Re: A problem with MAXPATHLEN on a back

看板FB_stable作者時間14年前 (2012/03/04 02:01), 編輯推噓0(000)
留言0則, 0人參與, 最新討論串1/2 (看更多)
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 _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
文章代碼(AID): #1FKbnhOV (FB_stable)
文章代碼(AID): #1FKbnhOV (FB_stable)