I'm trying to test my software project under WSL2 but am encountering an odd issue cloning the remote repository.

blah@DESKTOP-2P5VPVH:~/Blah$ fossil clone https://blah@blah.org:xxx blah.fossil
password for https://blah@blah.org:xxx: 
remember password (Y/n)? y
Round-trips: 5   Artifacts sent: 0  received: 1783
*** time skew *** server is slow by 2.8 minutes
Clone done, wire bytes sent: 1561  received: 11581841  remote: redacted
Rebuilding repository meta-data...
  100.0% complete...
Extra delta compression... 6 deltas save 7,052 bytes
Vacuuming the database... 
project-id: 5305ba19dc00165f78cffd8011ee9476f6bb9155
server-id:  3252ffbac98aa6c2bbe41bcb60ec49cc3147da82
admin-user: blah (password is redacted)

Then

blah@DESKTOP-2P5VPVH:~/Blah$ fossil open blah.fossil 
repository does not exist or is in an unreadable directory: /home/blah/Blah

At first I thought it was a permissions issue, but prefacing the fossil command with sudo changed nothing.

This is fossil version 2.24 [2ac49d3200] 2024-02-24 16:31:31 UTC

Please advise, thanks.

Is ~/Blah a real directory in your WSL2 container, thus on a proper Linux filesystem, or is it a symlink out to /mnt/c/Something/Else, thus on NTFS?

pwd does not indicate it's under /mnt/, but under the usual /home/ directory.

That's not what I asked. I asked if you've cd'd via a symlink or into a real directory. The output of "stat -c '%F' Blah" will differ between the cases.

Not a symlink, according to file.

Then I would guess you've got one of those hyperaggressive "antimalware" malware packages running, and it's screwing with the permissions.

That, or a locked-down corporate desktop.

Standard WSL2 install on an admin enabled machine. Nothing special or otherwise noteworthy at all.

I'll add also that this behavior is present on fossil 2.23, and, this repository seems to have a requirement to live in my home directory.

blah@DESKTOP-2P5VPVH:~/test$ ../fossil open https://blah@blah.org:xxx/repo_name
repository does not exist or is in an unreadable directory: /home/blah/repo_name

Notice that I am in the test directory under my home directory.

Sorry for the confusing redactions, but I don't want to share those details.

What I am expecting is that fossil "open" (or unpack) the repository file under the current working directory, but something is going haywire.

🤷‍♂️ It works here:

$ mkdir test      # real directory, not a symlink into C:
$ cd test
$ fossil open https://fossil-scm.org/home
$ cat VERSION
2.24

I replicated that test on two significantly different Parallels VMs. Both were running Ubuntu LTS atop Windows 11, but everything else differs. One is the M1 Mac running ARM64 Windows that I reported initial success with, but because that required use of WSL1 due to lack of nested virtualization on that platform, I'm updating this post to report a second round of success with WSL2 on an Intel VM.

The M1 instance used a regular Pro license of Windows, whereas with the Intel box, I used the Windows 11 Development VM because I was unwilling to get a second Windows license for this test.

I'm updating this post because WSL1 vs WSL2 isn't a small difference. WSL2 uses real Linux filesystems like ext4, whereas WSL1 uses a virtualized "wslfs" layer atop NTFS, bringing the same potential for permission weirdness as when using /mnt/c/… paths on WSL2. There was a real possibility that this mattered to the OP's reported symptom, but no:

me@WinDev2311Eval:~/src/fossil/trunk$ ./fossil ver
This is fossil version 2.24 [a7255ba561] 2024-02-29 19:48:11 UTC

So I tried this:

blah@DESKTOP-2P5VPVH:~/test$ fossil open https://fossil-scm.org/home
repository does not exist or is in an unreadable directory: /home/blah/Blah

blah@DESKTOP-2P5VPVH:~/test$ fossil close
repository does not exist or is in an unreadable directory: /home/blah/Blah

Which is nonsense.

Have I gotten fossil into some odd global state somehow?

Apparently fossil spawned a hidden .fossil and .fslckout file in the parent directory (maybe I was playing with command line options there) and these apparently set state for fossil.

I removed them and now it works. Not sure what happened exactly but this interaction was rather confusing.

The first is the global settings file. It's supposed to be there.

The second indicates that you tried to "open --force" the repo in the home directory, blasting its contents over the top. It would have warned you about this when you tried it first without the --force flag.

Yes, that did happen. How could I have backed out of that -- clearly Fossil was persisting in that well after the transaction had failed.

I was OK with forcing the import, in the sense of "yes fossil, unpack the files here regardless of what else exists in the directory". However, apparently the auto-sync failed, and it's rather opaque to the user what to do about this, heeded warning or not. Intuitively, I would've expected fossil close to resolve this, but it didn't, and I think we can all agree having a user delete a hidden file isn't ideal workflow.

This does sound more like deliberate self application of a foot-gun rather than a "workflow" though, to be fair.

I think the fact that fossil experts here couldn't diagnose the problem (and I do appreciate the help and rubber ducking) from fossil's diagnostic reporting is evident at least that could be improved. Having systems fail and recover gracefully is obviously a desirable property.

fossil's diagnostic reporting ... could be improved.

That's not evident to me from anything yet posted in this thread. The Fossil error message reported in post #1 says all that can reasonably be said by a program dedicated to Fossil's purposes rather than being an expert system familiar with all manner of emulated computing environments hosted in some other computing environment.

If the project's development team were to attempt the kind of improvement that would obviate human expert input regarding the environment(s) hosting a Fossil process and associated files, it would be a never-ending source of further improvement opportunities and a boundless time sink for development effort. Personally, I much prefer to see them improving Fossil itself -- effort which has proven to be quite beneficial.

Agreed. I spent the last half hour trying to replicate the failure, but somehow cannot anymore. Unfortunately the terminal history is also lost.