From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-f48.google.com ([209.85.214.48]:37783 "EHLO mail-it0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757471AbdCUTCN (ORCPT ); Tue, 21 Mar 2017 15:02:13 -0400 MIME-Version: 1.0 In-Reply-To: <20170321184401.GA32507@vader> References: <20170321184401.GA32507@vader> From: Linus Torvalds Date: Tue, 21 Mar 2017 12:02:11 -0700 Message-ID: Subject: Re: [RFC PATCH v2 1/2] fs: add AT_REPLACE flag for linkat() which replaces the target To: Omar Sandoval Cc: Al Viro , linux-fsdevel , Linux API , kernel-team , Xi Wang , Omar Sandoval Content-Type: text/plain; charset=UTF-8 Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, Mar 21, 2017 at 11:44 AM, Omar Sandoval wrote: > > This is actually the exact same check we have in vfs_rename(): Hmm. That looks bogus too exactly due to the overlayfs issues. Oh well. I guess people don't actually use overlayfs and care. > I tried to keep the same semantics as rename(). Ok, it does seem to match the non-exchange rename(), which I guess is what we want. It does worry me a bit that we only check for "may_delete()" even though we end up replacing it with a new one, but apparently those semantics indeed aren't new. Linus From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Subject: Re: [RFC PATCH v2 1/2] fs: add AT_REPLACE flag for linkat() which replaces the target Date: Tue, 21 Mar 2017 12:02:11 -0700 Message-ID: References: <20170321184401.GA32507@vader> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <20170321184401.GA32507@vader> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Omar Sandoval Cc: Al Viro , linux-fsdevel , Linux API , kernel-team , Xi Wang , Omar Sandoval List-Id: linux-api@vger.kernel.org On Tue, Mar 21, 2017 at 11:44 AM, Omar Sandoval wrote: > > This is actually the exact same check we have in vfs_rename(): Hmm. That looks bogus too exactly due to the overlayfs issues. Oh well. I guess people don't actually use overlayfs and care. > I tried to keep the same semantics as rename(). Ok, it does seem to match the non-exchange rename(), which I guess is what we want. It does worry me a bit that we only check for "may_delete()" even though we end up replacing it with a new one, but apparently those semantics indeed aren't new. Linus