-
-
Notifications
You must be signed in to change notification settings - Fork 351
Cannot fetch pytorch
repo as it can't acquire lock for reference update
#595
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
Comments
It turns out that despite best attempts to release tempfiles right after using them, this doesn't actually happen here which leads to the system exhausting its file handles. This shows up as From all I can tell, the resources are cleaned up immediately, and it's a bit of a puzzle as to why this isn't actually happening. |
Since the error kind is It turns out that it ultimately creates these errors here. When looking at it permanently failing the program actually has no tempfile open anymore (they are held only as long as needed, not more than one at a time), yet this one keeps erroring. Strangely enough this happens because the system still yields errors. |
It took longer than I admit (due to tooling also being case-sensistive by default) to figure out the following:
Indeed, there are two refs with the same name on case-sensitive file systems. Along with There are two issues I see
The solution here would be to avoid trying to handle colliding ref-names in the same transaction, and of course that should be done transparently. Tests for this are missing but could easily be added and tested on sensitive file systems like the ones on MacOS or Windows.
|
…595) Instead of moving them into place, we just drop them, without ever writing into them.
…a pending change. (#595) As opposed to dropping the Transaction, this method allows to obtain all edits that would have been applied.
…and fail as apparently probing really needs the right directory to work as expected. Or is there anything else?
Right now they only appear to be locks already taken, not the best UX for sure, but a starting point.
…ating the iterator. (#595) Previously, it would fail on first iteration, making it seem like there is one reference even though it's just an error stating that the base cannot be read. This is clearly worse than making a metadata check on the filesystem, no matter how unlikely the case.
…ase, correctly yield zero references. (#595) Previously it reported an error, now it does not and instead performs no iteration, which is more helpful to the user of the API I believe as they won't randomly fail just because somebody deleted the `refs` folder.
…ase-insensitie filesystems*. (#595) The asterisk indicates that this only works if packed-refs are present and these references are written straight to packed references without ever trying to handle the otherwise conflicting loose reference files. This is done by leveraging the fact that in presence of packed-refs or a pending creation of packed-refs, there is no need to create per-file locks as concurrent transactions also have to obtain the packed-refs lock and fail (or wait) until it's done.
…ock is helt. (#595) The logic is similar to what's done with updates.
#595) Previously it was possible for symbolic refs to be deleted right after they have been created or updated as they were included in the set of refs that was assumed to be part of packed-refs, which isn't the case for symbolic refs.
Closing as a fix is available in |
Reproduction
git clone https://github.com/pytorch/pytorch cd pytorch gix -v fetch
The above results in the following error:
The text was updated successfully, but these errors were encountered: