Benjamin Cairns

I also have this problem, again found via `usethis::use_data()`, where for example I would see: ```r usethis::use_data(object) #> Error: [EPERM] Failed to realize 'J:/path-to-package-dir': operation not permitted #> In addition:...

Encountering this again, I have dug further. The bug appears to occur in `realize_`, in [src/path.cc](https://github.com/r-lib/fs/blob/6ee3322076bd2cb6b9cacd0b52ac1717b11996e4/src/path.cc). But, I think that's not the origin of the bug. For that it appears...

I've had a go at a work-around for this - basically a fallback to `path_norm()` in case of error. My first attempt (referenced above) added a new argument, but I...

@jimhester Thank you for the reply. Yes, it doesn't look simple at all. I will keep looking for a solution - what are the requirements? Creating a test for Travis...

For the benefit of anyone who has this issue, and pending a real solution, I've written a guide on how to (easily) install the work-around directly from my fork. Full...

@ckirkeby The solution I suggested should work if `base::normalizePath(path, mustWork = TRUE)` works, where `path` is a path to the network drive. If that function *does* work for you, I've...

Just to note, the commit jdblischak/workflowr@6d98dc98, which includes a function to recursively resolve symlinks on Windows with `fs::path_real()`, does not solve the EPERM error that I get here. In particular,...

Jannis, The third argument to dde.pastvalue() is the "mark" number, indexed from 0. If I remember correctly -- and I admit there's a good chance I don't -- the number...

Thank you very much for this. Somewhat delayed by the Christmas break, but we are taking a look now. We think it is the result of a dependency API change...

We're making progress on this and it appears the original problem is solved, but in the process we have needed to rework the fix for additional issues like malformed files...