gel on Windows calculates path sha different than libraries

[nerdoza]

• Gel Version: 6.11+66a1377
• Gel CLI Version: 7.10.0-dev.1463+ff1bd8d
• OS Version: Windows 11

Steps to Reproduce:

1. Run gel project init in a project on Windows and the project will be initialized and a new gel.toml created, along with a corresponding [project-name]-[path-hash] directory in C:\Users\USER\AppData\Local\EdgeDB\config\projects.
2. Run any code using a gel library and the first database call will fail with a project is not initialized error.

Analysis:

The CLI, as of 482062b, is using dunce::canonicalize to generate the project path, which returns a path something like C:\Users\Zach\Dev\kaweah-tech\ff.app which generates a hash of be8268f00bfb7a7d249da0854ac91729624fdbf2. The project code appends a prefix of \\?\ to the path so it uses \\?\C:\Users\Zach\Dev\kaweah-tech\ff.app to generate a hash of f660887260d84cf3ecb590335ddff78600bbbad1. The end result is that the project code is looking for a config file ff.app-f660887260d84cf3ecb590335ddff78600bbbad1 which doesn't exist because the CLI created the config at ff.app-be8268f00bfb7a7d249da0854ac91729624fdbf2.

I believe this is an issue with all the libraries based on this search, so I suspect the fix needs to be made in the gel-cli project to reduce the amount of potential turbulence.

[mmastrac]

I suspect we are incorrectly using the Rust canonicalize function somewhere in the CLI which means this is definitely a bug.

[jakubmazanec]

When will this be fixed please? It has been two weeks. This bug makes Gel practically unusable on Windows - I don't want to specify connection parameters manually every time.

[nerdoza]

When will this be fixed please? It has been two weeks. This bug makes Gel practically unusable on Windows - I don't want to specify connection parameters manually every time.

Not the greatest solution ever, but if you want to resolve this bug locally, you can go into the C:\Users\USER\AppData\Local\EdgeDB\config\projects directory and copy the offending project directory, then rename the copied directory using the correct SHA1 hash generated by adding \\?\ to the beginning of the path.

Example

For directory Dev/test with a path of C:\Users\USER\Dev\test the CLI will generate a config directory C:\Users\USER\AppData\Local\EdgeDB\config\projects\test-4fe222cc35d3fa9905e6777b5f594ada43edb41e.

Copy the test-4fe222cc35d3fa9905e6777b5f594ada43edb41e directory to test-4fe222cc35d3fa9905e6777b5f594ada43edb41e (copy) or whatever.

Then take the path into a SHA1 tool and enter the full path (C:\Users\USER\Dev\test) which would show a hash of 4fe222cc35d3fa9905e6777b5f594ada43edb41e. (This is just a confirmation step. If the output hash doesn't match your config folder something in your path is wrong).

Then, append \\?\ to the beginning of the path, making it \\?\C:\Users\USER\Dev\test which changes the hash output to 038431074896c56e674af837a2a125ee2410aa1e. Take the generated hash and update your copied directory by replacing the hash portion. The result should be a directory like C:\Users\USER\AppData\Local\EdgeDB\config\projects\test-038431074896c56e674af837a2a125ee2410aa1e which has identical content to your original directory.

Note

This is a temporary solution and will break if you make changes to your project like renaming the instance or updating the project location. In those instances, remove the duplicate directory and walk through these steps again.