Skip to content
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

Open
Mara-Li opened this issue Jan 27, 2024 · 9 comments
Labels
bug Something isn't working

Comments

@Mara-Li
Copy link
Contributor

Mara-Li commented Jan 27, 2024

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

 Quartz v4.1.5 

Cleaned output directory `public` in 5ms
Found 44 input files from `content` in 19ms
Parsed 44 Markdown files in 2s
Filtered out 0 files in 243μs
Emitted 194 files to `public` in 512ms
Done processing 44 files in 2s
Started a Quartz server listening at http:https://localhost:8080
hint: exit with ctrl+c
[200] /
[200] /index.css
[200] /prescript.js
[200] /postscript.js
[200] /static/contentIndex.json
[200] /static/icon.png
Detected a source code change, doing a hard rebuild...


 ERROR 


Exiting Quartz due to a fatal error: EPERM: operation not permitted, unlink 'E:\Documents\Github\mara-quartz\public\static\icon.png'

Desktop (please complete the following information):

  • Quartz Version: 4.1.5
  • node Version: v18.18.0
  • npm version: 10.3.0
  • OS:Windows and WSL2 (Ubuntu)
  • Browser Firefox

Additional context
Probably linked to #692 #695

@Mara-Li Mara-Li added the bug Something isn't working label Jan 27, 2024
@lucastucious
Copy link
Contributor

lucastucious commented Jan 29, 2024

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
Copy link
Contributor Author

Mara-Li commented Jan 29, 2024

Yes, I noted the same thing

@kabirgh
Copy link
Contributor

kabirgh commented Feb 2, 2024

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
Copy link
Contributor Author

Mara-Li commented Feb 2, 2024

Yeah, I think Partial will reduce/remove this

@kabirgh
Copy link
Contributor

kabirgh commented Feb 11, 2024

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

@ghost
Copy link

ghost commented Feb 12, 2024

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
Copy link
Contributor Author

Mara-Li commented Feb 12, 2024

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.

@ghost
Copy link

ghost commented Feb 12, 2024

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants