8000 Early fail when output can not be created #346 by Spacetown · Pull Request #382 · gcovr/gcovr · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Early fail when output can not be created #346 #382

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Jun 3, 2020

Conversation

Spacetown
Copy link
Member

The options for output files are checked if the file is writable and the parent directory is writable.
Checks extended woth output files in non existing folders. Don't now how to check a write protected folder.

@codecov
Copy link
codecov bot commented May 31, 2020

Codecov Report

Merging #382 into master will increase coverage by 0.09%.
The diff coverage is 95.12%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #382      +/-   ##
==========================================
+ Coverage   94.56%   94.66%   +0.09%     
==========================================
  Files          18       18              
  Lines        2115     2154      +39     
  Branches      370      373       +3     
==========================================
+ Hits         2000     2039      +39     
+ Misses         55       54       -1     
- Partials       60       61       +1     
Impacted Files Coverage Δ
gcovr/configuration.py 96.88% <88.23%> (-0.64%) ⬇️
gcovr/html_generator.py 95.67% <100.00%> (+0.11%) ⬆️
gcovr/tests/test_args.py 100.00% <100.00%> (ø)
gcovr/gcov.py 87.86% <0.00%> (+0.03%) ⬆️
gcovr/__main__.py 90.43% <0.00%> (+0.95%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 56e2b2e...e4a058b. Read the comment docs.

@Spacetown Spacetown force-pushed the check_output_arguments branch from b433336 to 174ca99 Compare June 1, 2020 18:32
Copy link
Member
@latk latk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this, this is great as usual! But I think I've stumbled upon a larger bug in gcovr's config file handling 🤔, and I have opinions on error message phrasing.

None of those are blockers for this PR, so just let me know if you'd want to merge directly or use this space for further discussion first.

I'm not enthusiastic about the low code coverage for this patch, but I don't see how it could be tested reliably, so this is fine.

@Spacetown
Copy link
Member Author

I've tried to add a test with a temporary file and using chmod but it didn't work. Maybe this is because I'm running the test in Docker.

@Spacetown Spacetown force-pushed the check_output_arguments branch from 1a51fe7 to dcf1077 Compare June 2, 2020 07:51
@latk
Copy link
Member
latk commented Jun 2, 2020

Testing permissions is going to be somewhat nonportable, at least when Windows is involved. Otherwise, chmod 444 file should create a file that is readable and deletable but not writable. Unfortunately, the tests in Docker run as root and ignore the missing write permission.

But given the difficulties involved, it's OK if the test is skipped. Gcovr isn't that critical, so some amount of testing in “production” is fine :)

@Spacetown
Copy link
Member Author

What about to change to the python way. Instead of doing all the checks for the permission try to write the file and unlink it?

@Spacetown
Copy link
Member Author
Spacetown commented Jun 2, 2020

I'm trying to solve the problem found within the new config test. Jinja fails if the template is in a sub directory, in docker it works.
Should this be solved in this PR or should I create a separate one?
--> Solved in this PR by replacing FileSystemLoader with FunctionLoader for user template.

@Spacetown Spacetown force-pushed the check_output_arguments branch 2 times, most recently from ef29e79 to cefdfe2 Compare June 2, 2020 22:25
The FileSystemLoader does not support templates in sub directories on Windows (appveyor).
@Spacetown Spacetown force-pushed the check_output_arguments branch from cefdfe2 to e4a058b Compare June 2, 2020 22:39
@latk
Copy link
Member
latk commented Jun 3, 2020

What about to change to the python way. Instead of doing all the checks for the permission try to write the file and unlink it?

Well, there are tradeoffs. WIth the Python Way you presumably mean “it's better to ask forgiveness than permission”. That's generally sensible, but is also what we were doing previously: just try to create the report, and if it fails, it fails. Here, our goal is not to create the report, but to quickly alert the users about problems.

  • checking write permission and existence of directories
    (-) complicated
    (+) non-destructive
  • open the output file and delete afterwards
    (+) simple
    (-) has the effect of deleting the file

This differs in the outcome if gcovr crashes between the test and writing the report. I think there's a 10% chance of someone complaining about this in the future, but the simple destructive check is not incorrect.

Should this be solved in this PR or should I create a separate one?
--> Solved in this PR by replacing FileSystemLoader with FunctionLoader for user template.

Thanks for the fix! Jinja is geared towards a web context where there are different security concerns than we have, so apparently it takes some extra work to load arbitrary files.

@latk latk merged commit 39f5a82 into gcovr:master Jun 3, 2020
@latk latk added Type: Enhancement cli relating to the command line interface or the config system labels Jun 3, 2020
@Spacetown Spacetown deleted the check_output_arguments branch June 3, 2020 09:39
@latk
Copy link
Member
latk commented Jun 3, 2020

I've merged as-is. The tradeoff between different approaches relates to the concept of exception safety e.g. in C++ programming: things are safe if we end up in a valid state (and deleting files is valid), but under a stronger exception safety guarantee changes would be atomic: the attempted action either fails or produces an effect.

Since gcovr isn't a concurrent database system and since we don't make particular guarantees, deleting files during the check is fine.

@Spacetown Spacetown added this to the 4.3 milestone Oct 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cli relating to the command line interface or the config system Type: Enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
0