Native Windows port

[ThomasWaldmann]

If borg could run directly on a normal Windows installation (via cmd, not requiring cygwin or other major runtime support), it could be useful for windows machines that do not have cygwin installed.

Notes:

Doing a native windows port is likely quite some work over a longer time, due to all the differences between windows and UNIX-like operating systems. Whether it can be done in a pretty (regarding to source code changes) and good working (regarding to practical use) way has to be seen.

Because of that, it will have to live in a separate branch of the repository at first (which should be regularly updated from master branch, so it is kept up-to-date and without potential merge conflicts).

At some time in the future, that branch might or might not get merged into master.

---

:moneybag: there is a bounty for this

I opened a (first) bounty for this - if you would like to see this happen, feel free to support this or a future, related bounty.

The goal and scope of this bounty is:

• have a borg codebase that is able to run on native windows (without cygwin or similar runtime requirements)
• working basic borg commands: init, create, list, extract, delete
• working unit tests (failures in some of them that test stuff not in scope of the bounty are acceptable)
• initial documentation for developers and users (how to set up dev environment, how to install on a user system)
• not required: encryption, special windows file attributes support (like ACLs, xattrs), VSS support, installer

[ThomasWaldmann]

I don't know.

I only rarely test borg on cygwin, but i don't have a wsl nor a native win32 development system.

Yeah, someone(tm) could do that. Start with the simple stuff.

I think the initial goal should be something like "backup and restore my documents folder" rather than something with ntfs permissions / ACLs, special features, etc.

[Anakonda]

@henfri as the link says appveyour keeps artifacts only for 6 months. New ones are generated automatically as soon as something is pushed to the windows branch. If you have windows 10 I would suggest that you start using the openssh from microsoft. https://docs.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse

---

I have not tested the cygwin port, running with wsl should work as is.

Most of the code in windows branch can be used again when it is time to do Windows spesific stuff.

I could maybe do something if it were to master branch and not to windows branch.

[henfri]

Hi Thomas,

I understand. From a pure git perspective: Is there any help? I mean some way to look at the commits/changes in the windows branch and then try to merge them into the current master, showing conflicts and then, I could try to resolve them.

Regards, Hendrik

[ThomasWaldmann]

git show, git cherry-pick. not sure if there is something better / more comfortable.

[henfri]

@Anakonda thanks for your reply

I could maybe do something if it were to master branch and not to windows branch.

What do you mean by that?

[Anakonda]

I meant that its discouraging to see lot of commits pushed to master thinking I should merge them to windows branch. The merges I ended up doing were not easy. I don't want that mess again.

[henfri]

Hello,

I fully understand that. That is also my concern. I suppose you suggest that first your work should be merged into master, right?

@ThomasWaldmann What's your view on this? I think @Anakonda has a point here. I assume, you would merge, if the changes come in smaller pull requests?

Regards, Hendrik

[ThomasWaldmann]

I won't merge the windows branch "as is". It is beyond my capability to review or maintain it.

Also (IIRC) at least some of the changesets aren't very "clean" / "focussed".

Smaller, focussed, clean, "simple enough" PRs are welcome.

More difficult ones are welcome, too, if there is somebody reviewing them and there are windows developers being able to maintain the code.

[henfri]

Hello Thomas,

I fear, this way there is no way forward. I can understand Anakondas frustration/unwillingness to maintain the current approach of having to merge everything that is done in master into windows.

I have the impression that anakonda is willing to maintain the code. And I would use and test it.

So, what would be needed: 1) you to clarify what you did not find clean/focussed 2) anakonda to check whether smaller PRs are possible and whether he is willing to do these.

What do you think?

Greetings, Hendrik

[ThomasWaldmann]

the code should be reviewed by somebody with a clue of win32 api.

if it is unclear to @Anakonda what's unclean/unfocussed, i can point at it, but it might be rather obvious.

[henfri]

Hello,

I reviewed this one: https://github.com/borgbackup/borg/commit/126921da48aaa6cbb4434e4b69dd68b1e820f754 which is the initial commit. What I see that could be unclean is:

• UID/GID set to 0
• Mix of changes to make compatible to windows AND changes in order to be able to compile/install.

Apart from that, I do not see anything that could break functionality on non win32 platforms and nothing that would be 'dirty'.

Greetings, Hendrik

[Anakonda]

I suggest that we forget the windows branch for now, it is no way mergeable with master, instead start making (very) small changes to master. Maybe get pip install -e . to pass as first commit.

[luke-jr]

Can AppVeyor be restarted to regenerate the Windows builds? Presumably it's better than nothing?

[TheRealAlexV]

Would also like to see a windows version

[z11k]

+1 for win build

[maxkratz]

+1

[SpiderUnderUrBed]

+1

[SpiderUnderUrBed]

@ThomasWaldmann @henfri I am getting the FD exception problem, is there any way to fix that? like what ssh params can I change, and can this be fixed in windows/borg by any means?