[BUG]: (Windows) EPERM: Operation not permitted, unlink: '<folder>\public\static\icon.png' about quartz

[lucastucious]

I noted this happen much more when i edit, save, rebuild start, and i edit more + save BEFORE the first rebuild is done

[Mara-Li]

Yes, I noted the same thing

[kabirgh]

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 icon.png repeatedly when you're editing a markdown file.

[Mara-Li]

Yeah, I think Partial will reduce/remove this

[kabirgh]

@Lisandra-dev I've merged experimental support for partial rebuilds -- can you try with npx quartz build --serve --fastRebuild?

OS: Windows and WSL2 (Ubuntu)

@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., E:\Documents\Github\...) instead of the expected Unix-like format (i.e., /mnt/e/Documents/Github/...).

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 /etc/wsl.conf, but it is only safe to do so for drives that you only access from Linux, otherwise you may face disastrous consequences.

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.

[Mara-Li]

The wsl indication was just here because I tested in windows and WSL2.
I use windows in my workflows as WSL2 was just a test.

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.

[MaelImhof]

I also had an issue related to icon.png, with a slightly different error message, not sure the errors are related but I'll post here anyway:

Failed to emit from plugin `Static`: EPERM: operation not permitted, copyfile 'C:\path\to\quartz\static\icon.png' -> 'C:\path\to\public\static\icon.png'

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 --fastRebuild and the error does not show up anymore, however editing with Obsidian (which auto-saves very regularly) and fast rebuild is not so convenient since it rebuilds multiple times while I'm writing. Not that big of a deal, so I went with it, but I eventually got the same error as in #798 (heap overflow).

For now I'll just run build --serve when I want to see the website, but if anyone has a fix I would be happy to take a look at it.