From owner-freebsd-questions Mon Oct 14 17:15:48 1996 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA08017 for questions-outgoing; Mon, 14 Oct 1996 17:15:48 -0700 (PDT) Received: from freenet.hamilton.on.ca (main.freenet.hamilton.on.ca [199.212.94.65]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA08011 for ; Mon, 14 Oct 1996 17:15:30 -0700 (PDT) Received: from james.freenet.hamilton.on.ca (james.freenet.hamilton.on.ca [199.212.94.66]) by freenet.hamilton.on.ca (8.7.5/8.7.3) with ESMTP id UAA10571 for ; Mon, 14 Oct 1996 20:15:22 -0400 (EDT) Received: from localhost (ac199@localhost) by james.freenet.hamilton.on.ca (8.7.5/8.7.3) with SMTP id UAA18428 for ; Mon, 14 Oct 1996 20:17:11 -0400 (EDT) X-Authentication-Warning: james.freenet.hamilton.on.ca: ac199 owned process doing -bs Date: Mon, 14 Oct 1996 20:17:09 -0400 (EDT) From: Tim Vanderhoek Reply-To: Tim Vanderhoek To: freebsd-questions@freebsd.org Subject: fsck and MAXPATHLEN Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-questions@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I decided I would type cp -R .. . to see if cp had some check for exceeding MAXPATHLEN that I hadn't noticed in the source (which I was going through since I'm trying to rewrite a bit of it to fix that fact that mv doesn't work properly). (cp -R .. . will, of course, create an endless chain of directories, since as soon as it recurses from .. into ., . will have gained a new directory which will in turn be recursed into, and so on.) I wasn't surprised when cp itself didn't complain about not exceeding MAXPATHLEN, but I was surprised when the system (2.2-961006-SNAP) didn't complain. Further investigation showed that it was indeed exceeding MAXPATHLEN and that there were indeed the expected detrimental effects (ie. can't always determine CWD, or a sheared-off pwd). However, neither ufs nor fsck (on the still-mounted fs) complained about anything. This led me to suspect that MAXPATHLEN is just a suggestion that userland programs follow, and that there is no reason a userland program couldn't go beyond MAXPATHLEN if it wanted to? This theory would, of course, be fine except for the obvious fact that syscalls such as open(2) can have the error ENAMETOOLONG... So my question is thus -- Is MAXPATHLEN enforced, and who exactly is responsible for enforcing it? -- Outnumbered? Maybe. Outspoken? Never! tIM...HOEk