From: "Shawn O. Pearce" <spearce@spearce.org>
To: "Todd T. Fries" <todd@fries.net>
Cc: git@vger.kernel.org, Brandon Casey <casey@nrlssc.navy.mil>
Subject: Re: git on afs
Date: Sat, 20 Oct 2007 01:29:06 -0400 [thread overview]
Message-ID: <20071020052906.GT14735@spearce.org> (raw)
In-Reply-To: <200710190742.08174.todd@fries.net>
"Todd T. Fries" <todd@fries.net> wrote:
> It should not matter, but I'm using arla's afs client on OpenBSD; the errno
> is 17 (EEXIST), the very errno that bypasses the coda hack's rename():
...
> I can assure you that the 2nd argument to link does not exist ;-)
...
> The only downside is that either on coda or if the file already exists, it
> will try a spurrous rename(), in which case it will fail with EEXIST again,
> so I hope this is not a big negative.
Actually there is a really big downside. rename() is defined to
unlink the destination if it already exists, so you'll never get
EEXIST from a rename() call.
This means that an existing (known to be good) object can be
overwritten as a result of a rename with another copy of the object.
We've never really had that behavior as part of our security model
has been to always trust what is already in the repository and
refuse to replace something we already have.
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -2004,8 +2004,13 @@ int move_temp_to_file(const char *tmpfile, const char *filename)
> *
> * When this succeeds, we just return 0. We have nothing
> * left to unlink.
> + *
> + * AFS hack - afs is similar to coda, but inconveniently
> + * set errno to EEXIST, so call rename() if the link()
> + * above fails unconditionally. Small bit of extra work
> + * so afs functions properly.
> */
> - if (ret && ret != EEXIST) {
> + if (ret) {
> if (!rename(tmpfile, filename))
> return 0;
> ret = errno;
This is very unfortunate. There's no way to tell that the file
already exists. This whole AFS link() returning EEXIST is sort of
like the unlink() call on Solaris UFS working on directories as root
and leaving corrupted filesystems. At some point the application
just cannot be reasonably expected to work on a system that acts
this insane.
I think I would rather change sha1_file.c to write temporary files
into the destination directory, rather than one level up and try to
hardlink them into position. At least there we can rely on hardlinks
within Coda and AFS, and only need this rename special case for FAT.
--
Shawn.
prev parent reply other threads:[~2007-10-20 5:29 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-18 20:31 git on afs Todd T. Fries
2007-10-18 21:28 ` Brandon Casey
2007-10-18 21:57 ` Brandon Casey
2007-10-18 22:47 ` Linus Torvalds
2007-10-19 6:06 ` Shawn O. Pearce
2007-10-19 12:19 ` Todd T. Fries
2007-10-19 17:59 ` Linus Torvalds
2007-10-19 19:06 ` Linus Torvalds
2007-10-19 5:48 ` Shawn O. Pearce
2007-10-19 12:42 ` Todd T. Fries
2007-10-19 20:19 ` Daniel Barkalow
2007-10-20 5:29 ` Shawn O. Pearce [this message]
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=20071020052906.GT14735@spearce.org \
--to=spearce@spearce.org \
--cc=casey@nrlssc.navy.mil \
--cc=git@vger.kernel.org \
--cc=todd@fries.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).