Date: Mon, 25 Oct 2004 16:14:05 +0100
From: Christoph Hellwig <hch@infradead.org>
To: Mike Waychison <michael.waychison@sun.com>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
       raven@themaw.net
Subject: Re: [PATCH 25/28] VFS: statfs(64) shouldn't follow last component symlink
Message-ID: <20041025151405.GA1740@infradead.org>
Mail-Followup-To: Christoph Hellwig <hch@infradead.org>,
	Mike Waychison <michael.waychison@sun.com>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	raven@themaw.net
References: <10987158413464@sun.com> <10987158711277@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <10987158711277@sun.com>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1166
Lines: 23

On Mon, Oct 25, 2004 at 10:51:11AM -0400, Mike Waychison wrote:
> Mount-related userspace tools will require the ability to detect whether what
> looks like a regular directory is actually a autofs trigger.  To handle this,
> tools can statfs a given directory and check to see if statfs->f_type ==
> AUTOFSNG_SUPER_MAGIC before walking into the directory (and causing the a
> filesystem to automount).
> 
> To make this happen, we cannot allow statfs to follow_link.
> 
> NOTE: This may break any userspace that assumes it can statfs across a
> last-component symlink.  I can't think of any real world breakage however, as
> mount(8) will drop the real path in /etc/mtab and /proc/mounts will always
> show the true path.

Which means it's vetoed.  It's a big change in syscall semantics.  And
propabably breaks SuS (for statvfs(3) which requires full symlink
resolution when it just refers to a path on the filesystem.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/