I'm getting the below exception on a dvc pull (DVC v0.75.1) when my working copy (not remote) is on a networked Windows drive. The same config works fine on a local drive.
Traceback (most recent call last):
File "C:\Users\rxxg\dvc\lib\site-packages\dvc\main.py", line 49, in main
ret = cmd.run()
File "C:\Users\rxxg\dvc\lib\site-packages\dvc\command\data_sync.py", line 32, in run
recursive=self.args.recursive,
File "C:\Users\rxxg\dvc\lib\site-packages\dvc\repo\__init__.py", line 39, in wrapper
return ret
File "C:\Users\rxxg\dvc\\lib\site-packages\flufl\lock\_lockfile.py", line 338, in __exit__
self.unlock()
File "C:\Users\rxxg\dvc\lib\site-packages\flufl\lock\_lockfile.py", line 287, in unlock
raise NotLockedError('Already unlocked')
flufl.lock._lockfile.NotLockedError: Already unlocked
The problem seems to come from the flufl library, specifically, the call to _linkcount during an unlock and ìs_lockedoperation which finishes with a call toos.stat(self._lockfile).st_nlink` which yields 1 instead of the expected value of 2.
We can witness similar behaviour from the command line:
PS C:\Users\rxxg> echo asdf > lock
PS C:\Users\rxxg> fsutil hardlink create linked lock
Hardlink created for C:\Users\rxxg\linked<<===>> C:\Users\rxxg\lock
PS C:\Users\rxxg> fsutil hardlink list lock
\Users\rxxg\lock
\Users\rxxg\linked
PS C:\Users\rxxg> # worked fine on C:, let's try a network share
PS C:\Users\rxxg> h:
PS H:\> echo asdf > lock
PS H:\> fsutil hardlink create linked lock
Hardlink created for H:\linked <<===>> H:\lock
PS H:\> # hardlink has been created
PS H:\> fsutil hardlink list 'H:\lock'
Error: The request is not supported.
PS H:\> # But we can't verify its existence across a network boundary
I don't have access to the configuration of the network drive I'm afraid.
I'm getting the below exception on a dvc pull (DVC v0.75.1) when my working copy (not remote) is on a networked Windows drive. The same config works fine on a local drive.
The problem seems to come from the flufl library, specifically, the call to
_linkcountduring anunlockand ìs_lockedoperation which finishes with a call toos.stat(self._lockfile).st_nlink` which yields 1 instead of the expected value of 2.We can witness similar behaviour from the command line:
I don't have access to the configuration of the network drive I'm afraid.