It seems that fossil extra does not work if the working (checkout) directory is the root directory of a Windows drive.

In my case the checkout directory is on a network (samba) share and is mounted on Windows as T:. fossil extra shows nothing. If I share and mount the parent directory so that checkout is in a subdirectory, it goes back to normal and shows the extra files.

Is this a bug or a feature? :)

Emil

PS. This is fossil version 2.14 [815b4fc493] 2020-12-04 18:35:21 UTC on Windows 10

Confirmed!

• Using both fossil 2.14 and 2.15 (Win64, Windows 10) fails to list "extra" or "status --extra" when the checkout dir is at the root of disk.
• When checkout dir is at any subdirectory level, the "extra" commands return the expected output.
• Tested this on a local disk root.
• The add/commit works ok, so it's not file protection/permissions issue (at least not for the "extra" dirs and their contents)
• Same problem be it a regular command prompt or "Administrator" one.

Surprised that this issue so far has not prompted any replies from the leading devs. Hopefully they'll chime in soon. This seems to fall into a Basic Usage category.

This happens because when the repository is on the root of a Windows drive, its path contains no (back)slash. Adding a slash to get X:/ solves it.

For the proper patch somebody else will probably beat me to it.

Surprised that this issue so far has not prompted any replies from the leading devs.

Probably because the most active developers don't develop on Windows ;).

Hopefully they'll chime in soon. This seems to fall into a Basic Usage category.

On the contrary, any and all network-mounted usage of Fossil falls into the "Don't do That" category for reasons beat to death elsewhere.

The fossil repository is local, the checkout is on a network drive. OK, this leaves the _FOSSIL_ file, but anyway the checkout dir is not supposed to be used by multiple users simultaneously.

OK, this leaves the FOSSIL file, but anyway the checkout dir is not supposed to be used my multiple users simultaneously.

The problem is not only multi-user access, but locking and reliability of network-mounted storage. Hosting any and all sqlite files on a network mount is done at one's own risk, and i've yet to see anyone who has long experience with sqlite actually recommend using it over network mounts. Some will/do say, "it works for me," but it's always, since the Dawn of Time (as measured from the start of the SQLite Epoch) been a practice which has been recommended against.

i have to ask:

The fossil repository is local, the checkout is on a network drive.

If your repo is local, why on earth would you host the checkout on a network drive? What's the utility of that?

:)

There could be many reasons for that. In my case I'm working on Windows, but the network drive is on a headless linux and the checkout contains scripts that can only be executed on that specific linux box (via a separate putty session).

There could be many reasons for that.

You've yet to name one ;).

In my case I'm working on Windows, but the network drive is on a headless linux and the checkout contains scripts that can only be executed on that specific linux box (via a separate putty session).

Why not keep the repository on that same machine? Hypothetically you may want to access it from any number of workstations, but you've currently tied it to your one single Windows workstation. Aha... perhaps by "there could be many reasons for that" you're implying "job security" ;). (Not judging - that's between you and your employer.)

Related sidebar: NEVER, EVER, EVER share a single checkout with multiple copies of repository. (i say this because i half expect you to say that you'd just clone the repo to another Windows machine and add the same drive mapping.) The checkout db maps data in its repository db using integer record IDs. Those integers are transient and very often differ between clones of a given repository. If, e.g., you re-clone a repository and overwrite your prior copy, any checkouts made from the previous clone will be pointing to integers which do not really belong to it. Fossil (since relatively recently) tries to automatically recover from that, but if it cannot succeed then you'll need to do (fossil close --force; fossil open /path/to/repo --keep) to get it back in order.

Why are you opening a repository at the root of a drive? I think that is an extremely rare use-case. I mean, there is nothing that stops one from creating a drive dedicated to a project, but I would personally never do that. The root of a drive is for organizing directories, to the point that modern Windows really discourages you from creating files in the root. It's not impossible, but I would advise against it.

There is still something called "SUBST" in Windows, whose help reads, "Associates a path with a drive letter." The name dates back to the DOS days. It allows me to do something like: subst W: C:\Work\Projects\GizmosGalore\GizRepos\NewGizmoFeature234 , then work with that fingerful path at the (fake) root of (fake drive) W:.

I use it as a convenience sometimes, so I have no trouble imagining that I would run into this use-case. The only reason I have not is that I have the name W: mapped to GizRepos with check-outs in directories below that.

(Edit to make accursed backslashes visible.)

Not so rare if you consider USB drives. Many uses of USBs are on the root directory. And Fossil is ideally suited for that since it is self-contained.

SUBST too, as Larry says. SUBST can significantly improve speed in some cases, so that too is not so rare.

Dan Shearer

Fair points on SUBST and USB devices, though I still would use them as the root of an organizational structure vs a dedicated location for a single repo. It feels too much like someone trying to version their entire filesystem (like C:) or the root of their posix based system. Wrong tool for the job if that's what they're trying to do. But I certainly don't object if fossil supports it, as I am not forced to adapt my preferences accordingly.

I had just taken a debugger trip on this and I was thinking the same thing - there might be more to fix (or at least not to break), e.g. fossil clean -n fails on the same account.

I think one has to know the whole codebase pretty well to do that. And yes, it might not be worth the effort.

I had just taken a debugger trip on this

I should say I was pleasantly surprised by the C debugging experience inside VS Code (C/C++ Extension - minimal setting).

I understand this might not be worth the effort. I am fine with prohibiting the check-outs, or maybe even just a warning that certain commands are not expected to work in this case.

I don't think the topic should degrade into how right or wrong is it for Fossil to operate at filesystem root. There's nothing exotic about trying to version at a filesystem root (at least locally). Fossil can do this on Linux, should be able to do this on Windows. It's just a technical issue at the present stage of the codebase.

Out of curiosity, in a little investigative marathon I was able to make this sort of usage work properly, at least in the context of "extras". The bulk of changes revolved around the trailing-slash stripping/re-appending via (nRoot-1) and nPrefix which on Windows becomes peculiar due to disk-letter. Sure the full implementation needs to be more consistent and thoroughly tested as DRH pointed out.

The point is that it's very much doable.

Another discovery was also that "fossil extra /out-of-checkout-path" would still go on to scan the files (into vfile table) even though it's obvious that all of them should be disqualified by definition. Perhaps the out-of-checkout validation could be done sooner without the need to scan through such "external" dirs and add them into vtable.

Perhaps a better solution is to simply prohibit check-outs in the root directory of a windows machine...

In /chat, Daniel D. brought up a point about running fossil clean from such a checkout, perhaps inadvertently. That alone might justify a prohibition on root-dir checkouts, or at least justify displaying a huge warning banner to anyone who tries it. (After all, if we outright prohibit it then the Laws of the Universe will ensure that someone out there feels certain that they need that capability, and the Laws of the Internet will ensure that they find their way here. For each action there is an equal and opposite reaction.)