-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
[BUG]: (Windows) EPERM: Operation not permitted, unlink: '<folder>\public\static\icon.png' #737
Comments
I noted this happen much more when i edit, save, rebuild start, and i edit more + save BEFORE the first rebuild is done |
Yes, I noted the same thing |
I get this a lot too. I couldn't figure out why, but I'm working on partial rebuilds in #716, which help reduce the frequency of this problem. With partial rebuilds we will only write the files that have changed instead of cleaning the whole output directory and writing everything from scratch. In particular, this means we won't need to delete and copy |
Yeah, I think Partial will reduce/remove this |
@Lisandra-dev I've merged experimental support for partial rebuilds -- can you try with |
@Lisandra-dev, are you doing the Quartz build on bare metal Windows or on WSL2 as mentioned in the issue? I'm asking because it looks like you're actually doing this from Windows, as the path format is in the NT-styled format (i.e., If it is the case that you are running this in WSL2, I would follow the advice of Microsoft's Sven Groot: "if it's at all possible, store your projects in the Linux file system in WSL2." WSL2 accesses Windows files across the VM boundary through the 9P file system protocol, similar to the way QEMU provides host file access for its virtual machines. Typically, cross-VM file access tend to be slow, so various solutions employ caching to get around this. However, caching is implicitly disabled in this scenario, leading to severely degraded performance in many scenarios. You can enable it in your Even if you insist on keeping your projects on the Windows filesystem while working on them from WSL, you might face issues like microsoft/WSL#4739 and microsoft/WSL#4064. TL;DR: The interoperability between Windows and WSL2 filesystems is currently (and for the foreseeable future) not great. Please avoid this in your workflow, if possible. |
The wsl indication was just here because I tested in windows and WSL2. |
Sorry about that, then! At my previous job, I was the go-to in my team for headaches caused by WSL, and they really left a mark. Check out @kabirgh's recently-merged support for partial rebuilds, then — they might just squash this error for good. |
I also had an issue related to
I'm not using a symlink of any kind (normal directory) and I haven't done much configuration, but I had the same problem with many of my previous vaults as well. I tried For now I'll just run |
Describe the bug
Sometimes, one out of two, I have this error and the rebuild crash.
To Reproduce
On windows, run
npx quartz build --serve
, after one change (for example a SCSS custom files), the rebuild should crash.Expected behavior
Not a crash, a rebuild.
Screenshots and Source
Desktop (please complete the following information):
node
Version: v18.18.0npm
version: 10.3.0Additional context
Probably linked to #692 #695
The text was updated successfully, but these errors were encountered: