Seems like the second approach is correct, and it seems to have worked, did it not? What makes you think it didn't work?

The way clone (or sync) via SSH works is that it uses ssh to run the following command on the remote system:

fossil test-http REPONAME

Where REPONAME is the pathname of the ssh: URI. You want D:/_ssh/repositories/test.repo and so I think you want the second URI. The input and output to this command is the ordinary HTTP traffic that is normally sent over a network socket, though in this case it travels over the SSH connection instead.

The ssh command expects fossil to be on %PATH%. If it is not, you will need to use a query parameter to specify the Fossil binary:

 ssh://pcname/D:/_ssh/repositories/test.repo?fossil=c:/what/ever/fossil.exe

But I don't think you need to do this because apparently your second case worked, at least to judge from the output you got back.

I am sorry, I am not sure what you are talking about.

On Windows I am calling a ssh server. I do not work with putty, plink or any ssh client at all.

I don't know how to configure an ssh server on a Windows machine. That is not something I've ever done before, so cloning off of a Windows machine using ssh is not something I've ever tested. I've done it the other way around - Windows client and unix server - but I've never tried to clone onto a unix client from a Windows server.

Perhaps there is some \r\n translation issues messing up the protocol. The messages that go back and forth from client to server contain byte-counts, and so if extra \r characters get inserted or removed by SSH, then things will not go well. We've worked through all those issues for a Windows client hitting a unix server, but not the other way around.

Or it could be something else. I don't have any way of testing.

Have you considered just running "fossil server" on the Windows machine, then cloning or syncing using ordinary http:?

Thank you for trying to help.

My situation is the following: I am using privately svn since 15 years or more. Of course not many more ;-)

Now I am trying to go away from 2x desktop + 1x netbook + 1x server (24/7). I want to just remove my Jenkins/Nagios/Subversion/Reddit server and just have a repository on my desktop and another on on my Netbook, perhaps later on a laptop too. So... no server of any kind.

I hate git. I have used it for ca. 3 years on a daily basis and I have learned to really hate it.

So after some research I am currently thinking of using either fossil or mercurial. But copy-one-file-and-your-installation-is-done is such an unbeatable argument, I just HAD to try it.

Now the reason for my wall of text: I will perhaps have to sync different systems via WLan and I will not sync my personal data over WLan and http. Even https would be something I'd like to avoid. I just trust ssh more. No valid reason. It is just that way.

That is the reason I do not want to have fossil running as http server.

A possibility I am not so happy about even if it were possible, but I'd like to know if it IS possible: Can I temporarily start my normal no-server fossil as http server, connect via ssh and get the data from localhost:8080 or whatever port I'd use?

Http over ssh? If it is possible, how I start the http service (Windows and Linux please) and how would the connection line look like?

Sorry, I am stupid, that is what ssh tunnels are for. I'll try it perhaps the next days.

Other options to consider:

1. Put Fossil on a raspberry pi sitting somewhere in the corner, and use ssh: clones to the raspberry pi.

2. Help us debug the ssh: protocol when the server is a Windows machine.

3. Spend $5/month on a Linode or Droplet and host all your repos there, behind HTTPS. This gives you the added benefit of off-site backups.

My tip matters when the client is on the Windows side. I see on closer reading that your client is Linux instead, so it will use ssh commands for establishing the tunnel, not plink.

However, keep it in mind if you ever do Windows-to-Windows clones and sync.

It is just not working.

The repository on Windows has 3MB, 1 text file and one image (jpg).

I started the server with

fossil server -port 18080  test.repo

I created a tunnel and used the following config:

  Host desktop
        HostName                192.168.1.99
        User                    MyName
        Port                    22
        ServerAliveInterval     60
        LocalForward            18080 127.0.0.1:18080
        ForwardX11              yes

I connect via ssh

ssh desktop

and then in other terminal I do the cloning:

  fossil clone http://localhost:18080 test02.repo
  Round-trips: 2   Artifacts sent: 0  received: 4
  Clone done, sent: 469  received: 1365  ip: ::1
  Rebuilding repository meta-data...
  100.0% complete...
  Extra delta compression...
  Vacuuming the database...
  project-id: 3effc9d1ebdff561415fd287dce9c15177a94415
  server-id:  6951077b24e0c386a2db10a03b1832fdcdb0ab30
  admin-user: MyName (password is "adf13b")

So I get a valid repository. I only has a size of 229376 byes (instead of 3MB).

I do a

  fossil open ../test02.repo
  project-name: <unnamed>
  repository:   /home/MyName/test/j/../test02.repo
  local-root:   /home/MyName/test/j/
  config-db:    /home/MyName/.fossil
  project-code: 3effc9d1ebdff561415fd287dce9c15177a94415
  check-ins:    0

There is no data. No file. Nothing. The clone command worked normal, without error or anything weird.

I am going to bed. :-(

1. Help us debug the ssh: protocol when the server is a Windows machine.

I've set a ssh server on a windows-10 vm, and tried to clone it using --httptrace.

Then I did the same by cloning it with ssh://localhost/path/repo.fossil (MacOS).

When comparing the http-reply-<n>.txt files (converted in hex), I've notice that the clone done from the windows server contain an extra <0d> caracter at the end of each line.

On the good one, lines end by <0d><0a>, versus <0d><0d><0a> on the bad one.

Also, I've notice that the first reply was trunkated the middle of the "# timestamps ..." line and the rest of the line appears on the beginning of the next reply.

Here's my test repo with the httptraces files. https://drive.google.com/file/d/1ZglTjmGbz6GSHg-FgrkpOCZHt8c3ntCK/view?usp=sharing

(good/ is clone via ssh with macosx server while bad/ is via ssh with windows-10 server, the .xxd files are the files converted in hex using xxd utility)

I got sshd.exe running on my Windows10 machine, and was therefore able to reproduce the problem and fix it. If you install check-in 28b15b4816b9e05b or later on the Windows side, then ssh: should work work now.

I ran the following command from my linux desktop:

fossil clone 'ssh://drh@192.168.NNN.NNN/c:/fossils/sqlite.fossil' sqlite.fossil

An IP address of the Windows10 laptop was substituted for 192.168.NNN.NNN, of course. I keep my Fossil repositories in the C:/Fossils directory on the windows machine. I was prompted for a password, and the clone ran to completion and gave me a correct and complete repository.

Related Issue:

For the ssh: client on Windows, the default name of the ssh command is "plink". But now that Microsoft actually makes a working "ssh" command available on Windows, I wonder if we should change the default to be "ssh"?

This came up while I was testing the new code in the other direction - Windows client to linux server. I had to add the "-c ssh" option to the "fossil clone" command-line on Windows in order to get the clone to work.

Hi,

I just downloaded the Windows version yesterday: This is fossil version 2.9 [0fd79a3e09] 2019-07-13 13:05:19 UTC

With Debian 9 I just used what I got via apt-get This is fossil version 1.37 [463d2a7b49] 2017-01-18 12:25:23 UTC

After looking at this, I feel pretty stupid.

TESTING..........TESTING..........TESTING..........TESTING..........

IT WORKS!!!!

When I use the same version - the Windows AND Linux versions I downloaded yesterday, then I can clone the repository.

BUT: I can only open the cloned repository with the same version. I think the one from apt-get is just too old for the current format.

So....what I described in https://www.fossil-scm.org/forum/forumpost/eaf3ed51ae is working IF you use the same version on both sides.

I am sorry to not have seen this potential problem by myself.

Thanks Andy!

It works!!!!!!!!!!!!

With Debian 9 I just used what I got via apt-get

Debian 9 went out of support several months ago. You should upgrade to Debian 10, which ships Fossil 2.8.

IF you use the same version

The actual case is much less stringent than that: if you're using Fossil >= 2.1 on one side, you need to be using >= 2.1 on the other side, too, unless you go out of your way to allow use of Fossil 1.x.

Thus, using Fossil 2.9 on Windows with Debian 2.8 on Debian 10 is just fine.

Sorry, I did not see this message. I'll try this soon.

Do you guys see what is wrong?

According to your prior reply here, you're using the 2.9 release version on Windows, which doesn't have the fix drh just made for you. That means you can either wait for Fossil 2.10, or build Fossil from source, or hope someone else builds a binary for you. Me, I'd either build Fossil from source or switch to the Cygwin build, which won't have this problem. WSL won't have this problem, either.

Ah, sorry, do I need to build this myself or can I download the binary somehow?

the ssh:// URL is asking to run an unsafe command D://fossil.exe on the server.

...

I had to remove the .exe from the path to the fossil executable on Windows

FYI: This got fixed today here 8f70ccaac82d0e30. This is a fix for the client side.

Thank you for the information.