Just confirming - I am seeing this as well.

But the problem is even more complicated - the connection sometimes (not always) stays alive for a longer time after the sync is done. I have a script, where I automatically create a file, add & commit it and leave autosync to backup it on local server. Some *http files stay sometimes "alive" for relatively long time, meaning not even a minute delay after the autosync was finished is not enough time to allow for removing the files through the same script. In other cases, you could remove the files immediately, without any wait time. Not sure why there are the differences, the file is almost exactly the same every time, give or take a line or two. Of course there is a way how to handle this, but it is still interesting to see the difference.

And to make it even more difficult - in few test repos I managed to commit the *http files using the addremove & commit commands :) It was a good way to trigger the user review of the global ignore options, if nothing else.

Can you provide more details about how to reproduce this problem?

Can I assume that this is only happening on Windows?

For me, the same on Win10 64x, with the windows binaries (more often than not used from cygwin and from shell scripts).

The http files do come when syncing locally, using the file:// option. When I sync over http(s), nothing gets created or is visible.

Majka

OK, I managed to get more details to this problem:

Not sure if the reason is the combination of x64 system (win 10) and the provided windows binary, or the binary itself.

I have succeeded to compile the x64 binary under cygwin from source in downloads. The http (and some more problems I had) are not there any more, the file:// protokol works as well as the http(s) one.

If anybody is interested, I could post the compiled exe. It would work without cygwin as well, it just needs the cygwin1.dll in the same folder.

A Cygwin build is significantly different from a native Windows build.

I'd expect your symptom to come back with a MinGW build under Cygwin. I hope you try it, because it would be diagnostic either way.

I've never build Fossil that way, but it looks like you need to edit win/Makefile.mingw to switch to the appropriate PREFIX for the MinGW cross-compilers you've got installed under Cygwin, then say

  $ make -f win/Makefile.mingw

If you don't edit Makefile.mingw first, it'll expect to find gcc and such in the PATH and end up finding the Cygwin versions.

Never mind the warning at the top of the file not to edit it. It's just saying that if you want your edits to be permanent across Fossil versions that you don't want to edit the generated version. For one-off changes like this, you can edit Makefile.mingw directly.

I have no idea what, if any, libraries you've got to install to make this work. I suspect you'll have to go out of your way to get an SSL-capable build working, for example.

Unfortunatelly, I have to leave the win build to somebody else. I did try from latest source but didn't manage it.

I could replicate the issue using the downloaded v2.7 on win7 x64. Actually, both issues:

1. 'fossil sync' from file:// cloned repo leaves .http files behind (at the repo's dir)
2. 'fossil ui' for a repo that has a space in its path, throws a bad command message (breaking the path on the space and considering the right part of it as a command/exe

I haven't tried to debug it in depth, yet. But looking at some diffs between v2.6 and v2.7, here's some idea about unquoted file names, in src/winhttp.c

Possible?

I managed to locate the reason for the issue 2) above, please see src/backoffice.c

Looks like the 'fossil backoffice -R <repo>' command is being spawned without enquoting the repo path (Windows-only). Thus, when the originating repo has a space in its path, a main.c:find_repository_option() would just take whatever part before the first space in the repo path. Then db.c:db_open_repository() predictably fails to open and throws the fossil_fatal().

I have made enhancements that should address this issue. Please rebuild your fossil.exe binary using the latest sources and let me know if you continue to see problems.

DETAILS:

When using the file:// method for accessing a local repository, Fossil actually fires up a separate process running "fossil httpd" on that local repository. See the code at https://www.fossil-scm.org/fossil/artifact/18a06326d071?ln=270-282. After it finishes processing the single HTTP request, it tries to start backoffice, which is what prevents the *.http files from being deleted. So, I modified the "http" command to disable backoffice if the --in option is present.