Re: [PATCH] sha1_file: make sure correct error is propagated

[Francis Galiegue <fg@one2team.net>]

Le Friday 14 November 2008 20:50:09 Andreas Ericsson, vous avez écrit :
> Francis Galiegue wrote:
> > Le Friday 14 November 2008 20:05:19 Junio C Hamano, vous avez écrit :
> > [...]
> >
> >>>  	fd = mkstemp(buffer);
> >>> -	if (fd < 0 && dirlen && (errno != EPERM)) {
> >>> +	if (fd < 0 && dirlen && (errno != EACCESS)) {
> >>
> >> Is this accepting the two as equivalents???
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe git" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> > Well, looking at mkdir(2), it says:
> >
> >        EPERM  The file system containing pathname does not support the
> > creation of directories.
> >
> > Hmm, err... git would fail at an earlier point anyway, wouldn't it? Even
> > git init would fail there.
>
> Not necessarily. .git could be mounted erroneously from via a networked
> filesystem but without write permissions. 

In which case EACCESS would be returned anyway. There is quite a difference 
between EACCESS (Permission denied) and EPERM (operation not permitted).

Basically, my understanding is that mkdir() will only return EPERM if the 
underlying filesystem can not even CREATE directories on the filesystem. So, 
unless you are doing very bizarre things with your git repository, I cannot 
see how you can even trigger an EPERM unless you asked for it.

> Yes, other things would fail 
> then too, but both EPERM and EACCESS are valid and possible return codes.

And so is ENOSPC, and so is EIO, and so is... It's endless. I think focus 
should be made on the most common ones, and EACCESS _is_ such one. Others 
just aren't.

This is why I suggested replacing EPERM with EACCESS in the first place: 
EACCESS is by far the most common error code you will get (even root will get 
that on a read-only filesystem, not EPERM).

-- 
fge