From: Linus Torvalds <torvalds@linux-foundation.org>
To: Peter <vmail@mycircuit.org>
Cc: Git Mailing List <git@vger.kernel.org>,
Jeff Layton <jlayton@redhat.com>,
Steve French <sfrench@us.ibm.com>
Subject: Re: fatal: unable to write sha1 file git 1.6.2.1
Date: Tue, 24 Mar 2009 17:03:22 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.2.00.0903241655210.3032@localhost.localdomain> (raw)
In-Reply-To: <49C961D0.4010704@mycircuit.org>
On Tue, 24 Mar 2009, Peter wrote:
>
> Thanks a lot , I will check that out tomorrow, in the meantime, this is the
> result of your patch being applied:
>
> $ git add <big stuff>
>
> fatal: error when closing sha1 file (Bad file descriptor)
Ok, that's probably cifs_writepages() doing
open_file = find_writable_file(CIFS_I(mapping->host));
if (!open_file) {
cERROR(1, ("No writable handles for inode"));
rc = -EBADF;
} else {
..
so yeah, looks like it's the fchmod() that triggers it.
I suspect this would be a safer - if slightly slower - way to make sure
the file is read-only. It's slower, because it is going to look up the
filename once more, but I bet it is going to avoid this particular CIFS
bug.
Linus
---
http-push.c | 2 +-
sha1_file.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/http-push.c b/http-push.c
index 48e5f38..ba4fa4d 100644
--- a/http-push.c
+++ b/http-push.c
@@ -748,8 +748,8 @@ static void finish_request(struct transfer_request *request)
aborted = 1;
}
} else if (request->state == RUN_FETCH_LOOSE) {
- fchmod(request->local_fileno, 0444);
close(request->local_fileno); request->local_fileno = -1;
+ chmod(request->tmpfile, 0444);
if (request->curl_result != CURLE_OK &&
request->http_code != 416) {
diff --git a/sha1_file.c b/sha1_file.c
index 4563173..8268da7 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2285,9 +2285,8 @@ static void close_sha1_file(int fd)
{
if (fsync_object_files)
fsync_or_die(fd, "sha1 file");
- fchmod(fd, 0444);
if (close(fd) != 0)
- die("unable to write sha1 file");
+ die("error when closing sha1 file (%s)", strerror(errno));
}
/* Size of directory component, including the ending '/' */
@@ -2384,6 +2383,7 @@ static int write_loose_object(const unsigned char *sha1, char *hdr, int hdrlen,
close_sha1_file(fd);
free(compressed);
+ chmod(tmpfile, 0444);
if (mtime) {
struct utimbuf utb;
utb.actime = mtime;
next prev parent reply other threads:[~2009-03-25 0:08 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-24 18:20 fatal: unable to write sha1 file git 1.6.2.1 Peter
2009-03-24 19:30 ` Nicolas Pitre
2009-03-24 19:31 ` Linus Torvalds
2009-03-24 21:05 ` Peter
2009-03-24 22:30 ` Linus Torvalds
2009-03-24 22:42 ` Peter
2009-03-25 0:03 ` Linus Torvalds [this message]
2009-03-25 0:24 ` Jeff Layton
2009-03-24 23:35 ` Jeff Layton
2009-03-25 0:11 ` Linus Torvalds
2009-03-25 0:17 ` Steven French
2009-03-25 0:49 ` Jeff Layton
2009-03-25 10:52 ` Peter
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=alpine.LFD.2.00.0903241655210.3032@localhost.localdomain \
--to=torvalds@linux-foundation.org \
--cc=git@vger.kernel.org \
--cc=jlayton@redhat.com \
--cc=sfrench@us.ibm.com \
--cc=vmail@mycircuit.org \
/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