Re: [PATCH] log which temporary file could not be created

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Oct 10, 2010 at 01:09:09PM -0500, Jonathan Nieder wrote:
> Arnout Engelen wrote:
> > On Sat, Oct 09, 2010 at 09:41:24PM -0500, Jonathan Nieder wrote:
> >> 	fatal: Unable to create temporary file '.merge_file_Sc7R5c': File exists
> >> 	fatal: Unable to create temporary file 'newrepo/.git/tOWHcxk': No space left on device
> >
> > Perhaps we should also log the current working directory when the temporary 
> > filename is relative?
> 
> Let's step back for a moment.  Was there an example that prompted
> this patch?  

Yes: I was trying to do an initial push to a sf.net git repo, and this gave me:

arnouten@bird:~/asdf/notion$ git push sourceforge master
raboofje@xxxxxxxxxxxxxxxxxxxxxxxxxx's password: 
Counting objects: 21542, done.
Compressing objects: 100% (4179/4179), done.
fatal: Unable to create temporary file: Permission denied
error: pack-objects died of signal 13
error: pack-objects died with strange error
error: failed to push some refs to 'ssh://raboofje@xxxxxxxxxxxxxxxxxxxxxxxxxx/gitroot/notion/notion'
arnouten@bird:~/asdf/notion$

This seems to have been an error at the server side. I never did find out what
exactly went wrong - I just re-initialized the repo using the shell access and
all was fine after that.

> Were you aware of where git would be trying to create
> files in that example?  (I'm genuinely curious.)

No clue - but I'm not very into git 'internals' yet.

> Converting the filename to an absolute path with make_absolute_path
> might be useful, but I am not entirely sure it is worth the
> complication.
> 
> >> 	fatal: Unable to create temporary file '': Permission denied
> >>
> >> What should git do in this situation?
> >
> > Perhaps we should strdup() the template before mkstemp(), and log the 
> > strdup()'ed template when the original has been cleared?
> 
> Is it be preferable for the filename to always have XXXXXX in it?  If
> so, then copying it into a temporary buffer (on-stack, preferably)
> could be a sane solution, yes.

I'm not sure about 'always', but it'd be nice to have something to fall back 
to when the mkstemp clears the template.


Kind regards,

Arnout
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]