deepnight / ldtk

Modern, lightweight and efficient 2D level editor
https://ldtk.io
MIT License
3.45k stars 192 forks source link

Opening a .ldtk from within Windows Subsystem (WSL) fails to open and fails to load resources #1015

Open Samuel-Lewis opened 12 months ago

Samuel-Lewis commented 12 months ago

Heya! I'm finding there is a lot of troubles when loading/reading/writing any .ldtk files if they reside within my windows subsystem (WSL). LDtk works wonderfully when running on files located in Windows C drive.

The errors seem to indicate permission issues, but these permission issues seem to be unique to LDtk. Running as Adminstrator does not seem to help.

Environment

LDtk version: 1.4.1, 64bit OS: Windows 11 Home, 21H2

Steps to Reproduce

Creating

  1. Open LDtk from Windows Start Menu
  2. Click "New"
  3. Name and save to somewhere within WSL, eg: \\wsl.localhost\Ubuntu\home\user\my-project\world.ldtk

Expect: FIle to be created and project to open Actual: LDtk fails to create, showing error about lack of permissions

image

[SAVE]         2023-12-10 21:07:55   Preparing project saving: \wsl.localhost\Ubuntu\home\user\my-project\data.ldtk...
[SAVE]         2023-12-10 21:07:55   => PreChecks...
[ERROR]        2023-12-10 21:07:55   You don't have system permissions to access this directory!
[ERROR]        2023-12-10 21:07:55   Couldn't create this project file!

Opening

  1. Save/move a project to within windows subsystem. Eg path: \\wsl.localhost\Ubuntu\home\user\my-project\world.ldtk
  2. Double click the world.ldtk

Expect: File to open in LDTK Actual: LDTK opens, and fails to find project image

[BOOT]         2023-12-10 21:05:16   App started
[BOOT]         2023-12-10 21:05:16   Version: 1.4.1-64bits (build 471015)
[BOOT]         2023-12-10 21:05:16   ExePath: C:/Users/User/AppData/Local/Programs/ldtk
[BOOT]         2023-12-10 21:05:16   Assets: C:/Users/User/AppData/Local/Programs/ldtk/resources/app.asar/assets
[BOOT]         2023-12-10 21:05:16   ExtraFiles: C:/Users/User/AppData/Local/Programs/ldtk/extraFiles
[BOOT]         2023-12-10 21:05:16   CWD: \\wsl.localhost\Ubuntu\home\user\my-project
[BOOT]         2023-12-10 21:05:16   Display: 2560x1440
[BOOT]         2023-12-10 21:05:16   Args: soloValues=[\\wsl.localhost\Ubuntu\home\user\my-project\world.ldtk], args=[]
[FILE]         2023-12-10 21:05:16   Loading settings from C:/Users/User/AppData/Roaming/LDtk/settings...
[BOOT]         2023-12-10 21:05:16   AppZoomFactor: 1.3
[BOOT]         2023-12-10 21:05:16   Calling appReady...
[UPDATE]       2023-12-10 21:05:16   Looking for update
[BOOT]         2023-12-10 21:05:16   Start args: path=\wsl.localhost\Ubuntu\home\user\my-project\world.ldtk levelIndex=null
[BOOT]         2023-12-10 21:05:16   Loading project from args (\wsl.localhost\Ubuntu\home\user\my-project\world.ldtk)...
[ERROR]        2023-12-10 21:05:16   Project file not found
[ERROR]        2023-12-10 21:05:16   Failed to load project: \wsl.localhost\Ubuntu\home\user\my-project\world.ldtkIdx=null
[GENERAL]      2023-12-10 21:05:16   Page started: page.Home()
RPGillespie6 commented 9 months ago

I'm able to open .json project files in WSL, but it fails to find tilesets: image

I'm pretty sure the problem is related to string escaping. Note that in my image above, the path is \wsl.localhost\... which is incorrect, it should begin with a double slash: \\wsl.localhost\.... I think the double slash is being converted to a single slash somewhere which would cause WSL to search C: for the file instead of the mounted WSL drive.

Edit: @deepnight I'm 90% sure ldtk is normalizing path in a way that clobbers UNC paths and doesn't have anything to do with WSL specifically: https://learn.microsoft.com/en-us/dotnet/standard/io/file-path-formats#unc-paths. image

I think ldtk would have problems opening any UNC paths, not just WSL-related ones. I vote this issue be renamed to "Support UNC paths" or something.

As a workaround for WSL specifically, you can launch ldtk from WSL itself using the ubuntu appimage.

RPGillespie6 commented 5 months ago

I found a good workaround for this - map WSL to a letter drive with something like: image

See also: https://github.com/microsoft/WSL/issues/3854#issuecomment-631356968

This may even be a good enough workaround to close the issue.