Open brandonaut opened 4 years ago
Thanks for putting so much context in this report. I wonder if this is going to turn out to be a Windows-specific problem. Specifically, is it that files are getting created in the background, causing directory deletion to fail? (Should repro on both Windows and Unix in this case.) Or is it that file deletion is failing, because files are somehow open in the background. (Might repro only on Windows in this case.)
Would you have time to create a repro example using public GitHub repos? I haven't used LFS before myself, and a public repro would make it much easier to fix the bug.
Oops, somehow I got really mixed up. Neither repo is using Git LFS, so I'll have to figure out what other differences they have. One of the repos syncs fine, and the other gets the "directory is not empty" problem. I haven't been able to reproduce it in a public repo so far, but I'll keep you posted.
BTW, thanks for the quick response!
Running
peru sync
fails when syncing a repo that uses Git LFS. It seems that the clone into the.peru/tmp
directory succeeds, but when it tries to delete thetmp
directory, it fails because some of the files are still in the process of being deleted. A few seconds after I get this error message, I can see that all the files in thetmp
directory get deleted and the directory is, in fact, empty. Maybe this is a threading issue?Approximate
peru.yaml
:Stacktrace:
If I only sync modules that don't use Git LFS, it succeeds.
Environment