-
-
Notifications
You must be signed in to change notification settings - Fork 107
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
Handle Unwritable Path #47
Conversation
feee60f
to
bcc385f
Compare
Thank you! I can only run tests on linux at the moment, so I'd appreciate any feedback for other systems. |
@benediktschmitt I don't see these changes in master and it still seems to be a problem in the latest pip release #60. It looks like the changes are only in the branch |
I am very much interested in this fix. Indeed, we had two situations (after switching from a different lock implementation to filelock) in which SoftFileLock would just hang:
In both cases, one would expect an exception to be raised that allows to discriminate from an existing lock file. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you please rebase it on the latest main? You'll need to add some tests for it too, Thanks!
I included a test for the change in the original pull request 2+ years ago. Hopefully it should suffice. |
Oh missed that, still needs a rebase though 😊 |
Signed-off-by: Filipe Laíns <lains@riseup.net>
bcc385f
to
895b353
Compare
Codecov Report
@@ Coverage Diff @@
## main #47 +/- ##
==========================================
- Coverage 93.14% 86.61% -6.53%
==========================================
Files 2 2
Lines 394 411 +17
Branches 25 25
==========================================
- Hits 367 356 -11
- Misses 22 49 +27
- Partials 5 6 +1
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
I rebased the PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'll need to fix the tests and linting 👍
Yes, I had a look and the issues seem to be false positives (unless my english is rusty and there is actually a typo in words flagged). |
Signed-off-by: Bernát Gábor <bgabor8@bloomberg.net>
Superseded by #96 |
Description
If the OS cannot open a file because the path is bad, it does not make sense to repeatedly attempt to open the file as it will continue to fail, indefinitely if the
-1
default timeout is used, without any feedback to the user.This modifies the behavior to raise the OSError/IOError exception received on Windows or Unix so FileLock exits rather than a futile infinite loop that will never succeed.
Tests are written to demonstrate the behavior.