All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: dhowells@redhat.com, linux-fsdevel@vger.kernel.org, hch@lst.de,
	tytso@mit.edu, adilger.kernel@dilger.ca, darrick.wong@oracle.com,
	clm@fb.com, josef@toxicpanda.com, dsterba@suse.com,
	linux-ext4@vger.kernel.org, linux-xfs@vger.kernel.org,
	linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Making linkat() able to overwrite the target
Date: Tue, 14 Jan 2020 18:06:10 +0000	[thread overview]
Message-ID: <9351.1579025170@warthog.procyon.org.uk> (raw)
In-Reply-To: <20200114170250.GA8904@ZenIV.linux.org.uk>

Al Viro <viro@zeniv.linux.org.uk> wrote:

> > Would it be possible to make linkat() take a flag, say AT_LINK_REPLACE,
> > that causes the target to be replaced and not give EEXIST?  Or make it so
> > that rename() can take a tmpfile as the source and replace the target with
> > that.  I presume that, either way, this would require journal changes on
> > ext4, xfs and btrfs.
>
> Umm...  I don't like the idea of linkat() doing that - you suddenly get new
> fun cases to think about (what should happen when the target is a mountpoint,
> for starters?

Don't allow it onto directories, S_AUTOMOUNT-marked inodes or anything that's
got something mounted on it.

> ) _and_ you would have to add a magical flag to vfs_link() so
> that it would know which tests to do.

Yes, I suggested AT_LINK_REPLACE as said magical flag.

> As for rename...

Yeah - with further thought, rename() doesn't really work as an interface,
particularly if a link has already been made.

Do you have an alternative suggestion?  There are two things I want to avoid:

 (1) Doing unlink-link or unlink-create as that leaves a window where the
     cache file is absent.

 (2) Creating replacement files in a temporary directory and renaming from
     there over the top of the target file as the temp dir would then be a
     bottleneck that spends a lot of time locked for creations and renames.

David


  reply	other threads:[~2020-01-14 18:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-14 16:34 Making linkat() able to overwrite the target David Howells
2020-01-14 17:02 ` Al Viro
2020-01-14 18:06   ` David Howells [this message]
2020-01-14 19:37     ` Miklos Szeredi
2020-01-17  0:46     ` Colin Walters
2020-01-17  9:57       ` Amir Goldstein
2020-01-17 11:42       ` David Howells
2020-01-17 16:22         ` Omar Sandoval
2020-01-17 16:39           ` David Howells
2020-01-15  8:36 ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9351.1579025170@warthog.procyon.org.uk \
    --to=dhowells@redhat.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=clm@fb.com \
    --cc=darrick.wong@oracle.com \
    --cc=dsterba@suse.com \
    --cc=hch@lst.de \
    --cc=josef@toxicpanda.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=tytso@mit.edu \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.