Re: [Gnucash-changes] r12132 - gnucash/trunk - Don't chown() the owner,

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [Gnucash-changes] r12132 - gnucash/trunk - Don't chown() the owner,

Chris Shoemaker
On Mon, Dec 05, 2005 at 03:39:35PM -0500, Christian Stimming wrote:
>  #if VFAT_DOESNT_SUCK /* chown always fails on vfat fs */
> -                g_free(tmp_name);
> -                return FALSE;
> +                /* g_free(tmp_name);
> +   return FALSE; */
>  #endif

Is this your prediction that VFAT will never not suck?  :)

-chris
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Gnucash-changes] r12132 - gnucash/trunk - Don't chown() the owner,

Christian Stimming
Chris Shoemaker schrieb:

> On Mon, Dec 05, 2005 at 03:39:35PM -0500, Christian Stimming wrote:
>
>> #if VFAT_DOESNT_SUCK /* chown always fails on vfat fs */
>>-                g_free(tmp_name);
>>-                return FALSE;
>>+                /* g_free(tmp_name);
>>+   return FALSE; */
>> #endif
>
>
> Is this your prediction that VFAT will never not suck?  :)

No, my point is written just two lines ahead of these ones: A failed
chown doesn't mean that the saving itself failed. So don't abort with an
error here!

Christian
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Gnucash-changes] r12132 - gnucash/trunk - Don't chown() the owner,

Derek Atkins
Christian Stimming <[hidden email]> writes:

> Chris Shoemaker schrieb:
>> On Mon, Dec 05, 2005 at 03:39:35PM -0500, Christian Stimming wrote:
>>
>>> #if VFAT_DOESNT_SUCK /* chown always fails on vfat fs */
>>>-                g_free(tmp_name);
>>>-                return FALSE;
>>>+                /* g_free(tmp_name);
>>>+   return FALSE; */
>>> #endif
>> Is this your prediction that VFAT will never not suck?  :)
>
> No, my point is written just two lines ahead of these ones: A failed
> chown doesn't mean that the saving itself failed. So don't abort with an
> error here!

You should check the errno value.  If the errno is ENOENT
then the saving failed.  If the errno is EPERM then we shouldn't
abort with an error..

> Christian

-derek

--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Gnucash-changes] r12132 - gnucash/trunk - Don't chown() the owner,

Christian Stimming
FTR, below is the (slightly edited) IRC discussion of this issue.

<cstim> warlord: re errno: If there were an ENOENT, then the chmod()
before would have signalled an error already.
<warlord> Ahh, I see.  If the save() failed it then checks..  it only
falls into the chown/chmod if the save fails and the stat() succeeds.
<cstim> "falls into"?
<cstim> If the save fails (the else-branch) then errno is checked.
<cstim> If the save succeeds, then stat() is done
<cstim> if stat() succeeds, then chown/chmod is done.
<warlord> correct.  that's what I meant. :)
<cstim> so if the chown() fails, we can't do anything about it anyway.
That's why I commented out any error message.
<cstim> BTW where is VFAT_DOESNT_SUCK defined?
<warlord> cstim: it's not defined anywhere.
<cstim> warlord: I see. http://svn.gnucash.org/trac/changeset/8947
<warlord> Yes.. The macro is never defined anywhere.  The point is that
VFAT SUCKS.
<cstim> oh does it? :-)
<warlord> Yes.
<warlord> The problem is there's no way to detect what filesystem is
underlying us..  and chmod() and chown() fail if we're sitting on vfat
(or smb)
<cstim> right
<cstim> but then the qof_backend_set_error in the chmod() should go
away, too
<cstim> because that ERR_BACKEND_PERM will cause a BIG FRIGHTENING ERROR
MESSAGE.
<warlord> Probably..  I think those were added later.
<cstim> yes they were.
<cstim> the ERR_BACKEND_PERM was added by linas in r9012
<cstim> http://svn.gnucash.org/trac/changeset/9012#file1
<warlord> Perhaps we need an ERR_BACKEND_CH_FAILED that causes a
different warning message?
<cstim> that would be fine, yes.
<warlord> but yes, the chown() and chmod() failures shouldn't be PERM

17:09 *** Saved text to #gnucash to C:\Programme\XiRCON\#gnucash.log


Derek Atkins schrieb:

>>>On Mon, Dec 05, 2005 at 03:39:35PM -0500, Christian Stimming wrote:
>>>
>>>>#if VFAT_DOESNT_SUCK /* chown always fails on vfat fs */
>>>>-                g_free(tmp_name);
>>>>-                return FALSE;
>>>>+                /* g_free(tmp_name);
>>>>+   return FALSE; */
>>>>#endif
>>>
>>>Is this your prediction that VFAT will never not suck?  :)
>>
>>No, my point is written just two lines ahead of these ones: A failed
>>chown doesn't mean that the saving itself failed. So don't abort with an
>>error here!
>
> You should check the errno value.  If the errno is ENOENT
> then the saving failed.  If the errno is EPERM then we shouldn't
> abort with an error..
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel