From mboxrd@z Thu Jan 1 00:00:00 1970 From: Trond Myklebust Subject: Re: How to handle non-local renames? Date: Thu, 28 Sep 2006 09:31:59 -0400 Message-ID: <1159450319.5439.44.camel@lade.trondhjem.org> References: <1158597517.6297.10.camel@lade.trondhjem.org> <1158883241.5535.7.camel@lade.trondhjem.org> <20060928100223.GY29920@ftp.linux.org.uk> <1159446678.5439.23.camel@lade.trondhjem.org> <20060928124247.GD29920@ftp.linux.org.uk> <1159448228.5439.26.camel@lade.trondhjem.org> <20060928131545.GF29920@ftp.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Miklos Szeredi , dhowells@redhat.com, linux-fsdevel@vger.kernel.org Return-path: Received: from pat.uio.no ([129.240.10.4]:58832 "EHLO pat.uio.no") by vger.kernel.org with ESMTP id S1161116AbWI1NcS (ORCPT ); Thu, 28 Sep 2006 09:32:18 -0400 To: Al Viro In-Reply-To: <20060928131545.GF29920@ftp.linux.org.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, 2006-09-28 at 14:15 +0100, Al Viro wrote: > > That would mean that I can in practice unmount directories on your > > client simply by renaming a directory on my client. I can't see how that > > would be acceptable either. > > And what are you going to do if I remove it and its ancestors on my client? If it is in a subdirectory to which you are not supposed to have write access, then I'm going to yell bloody murder :-) Ditto if the same thing happens when you rename a directory to which you do have access, and that screws over my process in a subdir to which you don't have access. The point is that NFS has quite enough posix violations already on its grubby little hands. As far as posix is concerned, renaming a parent is not supposed to affect processes in the subdirectories. There is currently no reason why we can't support that behaviour in the NFS client too barring VFS quirks. Furthermore, it would upset a lot of people to change the current behaviour which does support remote rename, and has supported it for the past 10 years at least. I'd therefore prefer to go for a workaround that addresses the problem of the deadlocks instead of the useful functionality.