Windows compatibility progress?

[parasiteoflife]

Hi, can you please tell us how advanced compatibility with Windows is? I would really like to try rustic but I only use Windows. I tried searching issues and discussions with the Windows keyword but found nothing and the readme only says is a WIP.
Thank you.

[aawsome]

To be honest, windows support is in an very early stage and needs help to get implemented.
The current state is that rustic doesn't even compile on windows - mostly because of file handling which is basically using unix-specific file permissions, file timestamps etc.
So, mainly the backends to read sources and write to targets need to get enhanced to support windows.

Next, tests should be run and maybe windows-specific treatments should be defined and tested.

I myself unfortunately don't even have direct access to a windows machine, so the only thing I can do is to run tests via the github pipeline.

So, all together - I think it isn't a really big deal, but I need help on it:

• help to fix compile errors
• help with tests
• help with windows-specific requirements

[aawsome]

I just rebased #11.

So far we get 35 compile errors - I think we have the following ToDos:

• adapt backend/ignore.rs
• adapt backend/local.rs
• make a own version of converting windows filenames to String in backend/node.rs
• consollidate the quick hack in cmd/restore.rs:528 with functionality within ignore.rs or local.rs
• use hack for SIGPIPE in main.rs only on unix systems

[aawsome]

@parasiteoflife I worked a bit on #11 and it is now in the state that with this PR, rustic compiles on windows.
Feel free to try it - but you so far have to compile it yourself from this PR.

I'll add pre-build binaries soon. What target architecture do you think should we use to compile for windows?
We have the following Rust targets available (but I don't know which do work, to be honest):

aarch64-pc-windows-msvc
i586-pc-windows-msvc
i686-pc-windows-gnu
i686-pc-windows-msvc
x86_64-pc-windows-gnu
x86_64-pc-windows-msvc

[aawsome]

I created #487 to track the state of how rustic supports windows. I however need help to finish all those issues - even though some might be pretty easy to do.

[aawsome]

PR #11 is now merged. That means, rustic now compiles on Windows. I would very much appreciate you to test it out and fill issues for missing or not working windows-related features. You can also add topics to #487.

The beta builds now also contain a pre-compiled Windows version of rustic.

[parasiteoflife]

thank you for all the work!
I'll try the new build as soon as I can.

[parasiteoflife]

treat non-unicode filenames and quoting of filenames correctly

I think this, as a non-English native speaker, will affect me the most, a lot of my files have accents, then I also have files with Japanese characters, I'm guessing I better wait until that gets implemented?

In any case, I'll have to wait until I can test rustic. But I'm wondering, could the restore command be completely read-only?

[aawsome]

I think this, as a non-English native speaker, will affect me the most, a lot of my files have accents, then I also have files with Japanese characters, I'm guessing I better wait until that gets implemented?

Actually not that much as unicode characters should basically work already.
The problem with the encoding is a different one:
A filename can also have non-unicode characters as it is just some bytes in unix (I don't know exactly on Windows, but I think it should be something like two-byte character - don't know if this restricted to unicode or not).
So restic had to be able to treat these non-unicode characters and therefore used a go-specific function to encode a filename into a string. This not only handles the non-unicode characters, but also introduces some escaping, e.t. for \ or ".
For unix I had to reverse-engineer this go-specific function as it is not really well documentd.
And I actually don't know what this go-specific function is doing on Windows.

So the best you can do is help by using all kind of weird filenames and backing them up with restic and rustic (this could be even within the same repository) and compare the trees generated (e.g. rustic cat tree) and the file list displayed by restic ls <snap> and rustic ls <snap>. And if you see any difference, please report it.

In any case, I'll have to wait until I can test rustic. But I'm wondering, could the restore command be completely read-only?

The restore command is read-only w.r.t. the repository.

[parasiteoflife]

Thanks for the clarification, I'll make an issue about the filenames.

The restore command is read-only w.r.t. the repository.

I was asking because right now I can't write to my rclone remote so no locks can be written to it but when I tried restoring with rustic I got some errors while it was building the cache, I guess that's trying to write to the repo? (All this in a Linux machine) Because trying to restore with restic using --no-lock works without problem.