After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 757442 - Fix permissions and error handling for GIR output files
Fix permissions and error handling for GIR output files
Status: RESOLVED FIXED
Product: gobject-introspection
Classification: Platform
Component: g-ir-scanner
unspecified
Other All
: Normal normal
: ---
Assigned To: gobject-introspection Maintainer(s)
gobject-introspection Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2015-11-01 18:02 UTC by Mikhail Zabaluev
Modified: 2015-11-01 23:28 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Don't lose output silently when overwrite of the output file is denied (904 bytes, patch)
2015-11-01 18:03 UTC, Mikhail Zabaluev
committed Details | Review
g-ir-scanner: Set sensible permissions on the output file (1.30 KB, patch)
2015-11-01 18:03 UTC, Mikhail Zabaluev
committed Details | Review

Description Mikhail Zabaluev 2015-11-01 18:02:55 UTC
There are a couple of issues with how the output file of g-ir-scanner
is renamed from the temporary work file. The patches change the
behavior to be more sensible.
Comment 1 Mikhail Zabaluev 2015-11-01 18:03:00 UTC
Created attachment 314582 [details] [review]
Don't lose output silently when overwrite of the output file is denied

If the move resulted in EPERM, discard the temporary output file, but
raise the error so that the tool exits with a nonzero status.
Comment 2 Mikhail Zabaluev 2015-11-01 18:03:08 UTC
Created attachment 314583 [details] [review]
g-ir-scanner: Set sensible permissions on the output file

If the file is new, set the permissions to 0644.
If the file with the name specified as --output exists, copy its
metadata onto the temporary output file.
Comment 3 Colin Walters 2015-11-01 19:56:01 UTC
Review of attachment 314582 [details] [review]:

Why only unlink on EPERM?  Looks like the code came from  dfff733b154abf1e85d447d2da389b34396fe005 - no rationale there.

I'm fine if you keep it as is or delete the if (eperm) bit.
Comment 4 Colin Walters 2015-11-01 19:58:51 UTC
Review of attachment 314583 [details] [review]:

I'd imagine there's a more idiomatic way to do this, like the equivalent of `g_file_replace()`, but the code looks fine.
Comment 5 Mikhail Zabaluev 2015-11-01 22:56:08 UTC
(In reply to Colin Walters from comment #3)
> Review of attachment 314582 [details] [review] [review]:
> 
> Why only unlink on EPERM?  Looks like the code came from 
> dfff733b154abf1e85d447d2da389b34396fe005 - no rationale there.

My guess is that EPERM is an expected outcome -- we know exactly what's wrong, so the temporary file is unnecessary for post-error analysis. In case of an unexpected exception, the partial output may give some clues.
Comment 6 Mikhail Zabaluev 2015-11-01 23:16:38 UTC
(In reply to Colin Walters from comment #4)
> 
> I'd imagine there's a more idiomatic way to do this, like the equivalent of
> `g_file_replace()`, but the code looks fine.

I have implemented it with Python context manager protocol elsewhere:
https://github.com/gi-rust/grust-gen/blob/master/grust/output.py#L25

In case of giscanner modules, however, this is the only place where a file created by tempfile.mkstemp() ends up being moved to become the eventual output file. If more reuse is needed, feel free to take code from my module.

Besides, the branch for --reparse-validate=no just opens the output file for overwriting. That might be good to switch to flash-cutover as well.
Comment 7 Mikhail Zabaluev 2015-11-01 23:26:42 UTC
Comment on attachment 314582 [details] [review]
Don't lose output silently when overwrite of the output file is denied

Pushed as commit 1754b3c
Comment 8 Mikhail Zabaluev 2015-11-01 23:27:46 UTC
Comment on attachment 314583 [details] [review]
g-ir-scanner: Set sensible permissions on the output file

Pushed as commit 40d8236