gnc-backend-file.c: ERR_BACKEND_PERM too unspecific

[Christian Stimming]

Ok, as you can see from the ChangeLog: We chown() now only for the group id, 
no longer for the user id. Also, an error here is only a warning, not an 
error.

There's still the open question about the severity when the chmod() fails. 
Right now this is presented as a fatal error to the user, although the "save" 
completed successfully already at that point. We should do something about 
this, too ...

My earlier statement wasn't fully correct; the chmod/chown is performed on the 
newly created file, not on the archived file. Both may have their reasons, 
but a failure in one of them is a different thing than a failure in the "save 
file" action. We need a different error code and error message for those 
cases, and currently we don't have it.

Christian

Am Dienstag, 29. November 2005 16:37 schrieb Derek Atkins:
> What I don't understand is why we're trying to chown() the
> file:
>
> [warlord at cliodev src]$ find . -name \*.c | xargs grep chown
> ./src/backend/file/gnc-backend-file.c:            if(chown(tmp_name,
> statbuf.st_uid, statbuf.st_gid) != 0)
> ./src/backend/file/gnc-backend-file.c:                PWARN("unable to
> chown filename %s: %s", ./src/backend/file/gnc-backend-file.c:#if
> VFAT_DOESNT_SUCK /* chown always fails on vfat fs */
>
> I think we're trying to retain the original owner/group, but that
> can't work because only the superuser can change the owner.  I think
> we should change this chown() call to:
>
>   chown(tmp_name, -1, statbuf.st_gid)
>
> This would retain the original group setting on the file, which should
> work provided the user is in the group.  Or we can just forego the
> group setting completely and assume the user has a proper setgid
> setting on the directory.
>
> -derek
>
> Tim Wunder <tim at thewunders.org> writes:
> > I don't see where Christian is talking about chmoding a backup file here.
> > I read this as him getting a warning when saving the data file. A warning
> > that caused the app to fail, and really wasn't the warning it thought it
> > was (the file was saved regardless of the warning). Regardless, an app
> > should not try to chmod *any* pre-existing data file. Sys admins assign
> > file permissions for a reason. Apps shouldn't attempt to change that
> > willy-nilly...
> >
> > Of course, I reserve the right to have misread what he wrote ;)
> >
> > Tim
> >
> > On Monday 28 November 2005 6:48 pm, someone claiming to be Derek Atkins 
wrote:
> >> I'm wondering why we even try to chown the old backup file at all?
> >> I can understand why we want to chmod the NEW data file, but I
> >> don't understand why we'd want to do anything but "rename" the
> >> old backup file?
> >>
> >> -derek
> >>
> >> Christian Stimming <stimming at tuhh.de> writes:
> >> > I just recently got a new error message from the gnucash-HEAD that
> >> > didn't show up with 1.8. Here's the deal: I have two linux users
> >> > accessing the gnucash file alternating. The directory of that file has
> >> > 775 permissions and both of them are in the same group, so both are
> >> > able to write the file in that directory.  However, on file saving in
> >> > 1.8 I always got the PWARN message on the cmdline saying that the new
> >> > user is "unable to chown filename", which was quite understandable
> >> > because the new user cannot chown the previous file that was written
> >> > by the old user. In 1.8 this was a not-too-noisy warning on the
> >> > cmdline.
> >> >
> >> > However, with SVN-HEAD on "save file" this "unable to chown filename"
> >> > warning in  src/backend/file/gnc-backend-file.c:556 results in a
> >> > ERR_BACKEND_PERM error code being passed to gnucash, which will then
> >> > show a big red error window saying "You do not have permission to
> >> > access %s\n"! Uh oh! Very frightening.