basiliscos / syncspirit

continuous file synchronization program (BEP protocol implementation)
GNU General Public License v3.0
31 stars 2 forks source link

Build for WindowsXP is posible? #3

Open devisbal opened 2 months ago

devisbal commented 2 months ago

Hi:

It will be possible to build for 32bits Windows XP this program syncspirit? We do have been using SyncThing on Windows XP, but those just are the latest posible we could compile/build that was: V1.6.1

BR

basiliscos commented 2 months ago

Hi,

I've made a i686-build, i.e. win32 (not win64) binary. I'm not sure , that it works on windows xp, please try the attached files.

Let me know the outcome!

windows-i686-support-libraries.zip

syncspirit-daemon.zip

devisbal commented 2 months ago

Hi:

I got the following error: syncspirit-daemon.exe - Entry Point Not Found The procedure entry point GetTickCount64 could not be located in the dynamic link library KERNEL 32. dll.

GetTickCount64 function: Minimum supported client Windows Vista So, there is not support for Windows XP. I did not see this used on your source, so it should be part of one of the external lib or mod used.

BR

basiliscos commented 2 months ago

What I have found that my compiler (mingw) is most likely compiled with default target to windows vista. It is something like that:

https://github.com/msys2/MINGW-packages/blob/4a7eb3e90bc008e80274b7d2968269a5ea38156c/mingw-w64-headers-git/PKGBUILD#L58

So, if you can build mingw on yourself (on linux machine) it should probably work, because I was able to compile it.

Here are a few patches:

diff --git a/src/utils/network_interface.cpp b/src/utils/network_interface.cpp
index 01558d8..034168d 100644
--- a/src/utils/network_interface.cpp
+++ b/src/utils/network_interface.cpp
@@ -115,8 +115,7 @@ static uri_container_t _local_interfaces(logger_t &log, std::uint16_t port) noex
                 // IPv4
                 SOCKADDR_IN *ipv4 = reinterpret_cast<SOCKADDR_IN *>(address->Address.lpSockaddr);

-                char host[INET_ADDRSTRLEN] = {0};
-                inet_ntop(AF_INET, &(ipv4->sin_addr), host, INET_ADDRSTRLEN);
+                auto host = inet_ntoa(ipv4->sin_addr);
                 auto full = fmt::format("tcp://{}:{}/", host, port);
                 auto uri = utils::parse(full).value();
                 r.emplace_back(std::move(uri));
 --- a/src/osal.c
+++ b/src/osal.c
@@ -1090,7 +1090,7 @@ MDBX_INTERNAL_FUNC void osal_ioring_reset(osal_ioring_t *ior) {
     for (ior_item_t *item = ior->pool; item <= ior->last;) {
       if (!HasOverlappedIoCompleted(&item->ov)) {
         assert(ior->overlapped_fd);
-        CancelIoEx(ior->overlapped_fd, &item->ov);
+        CancelIo(ior->overlapped_fd);
       }
       if (item->ov.hEvent && item->ov.hEvent != ior)
         ior_put_event(ior, item->ov.hEvent);

More building instructions u can find in doc/building.md.

PS. You can find whether it need windows-vista via the command grep -a GetTickCount64 *.dll

basiliscos commented 2 months ago

will try to build the mingw compiler by myself, not sure that it will be successful :)

devisbal commented 2 months ago

I could not find to patch: --- a/src/osal.c

basiliscos commented 2 months ago
-> % find . -iname 'osal.c'
./lib/mbdx/src/osal.c
basiliscos commented 2 months ago

I think I was able to build for windowx xp, but unfortunately libmbdx reports some error during startup. I have asked the libmbdx author whether it is possible to add windows xp support. Will let u know

syncspirit-daemon.exe.zip

basiliscos commented 2 months ago

I'll try to use a different db-engine (switcheable) for winxp, but probably in a next version.

The engines under consideration are:

https://github.com/pmwkaa/ioarena/tree/master/db

basiliscos commented 2 months ago

syncspirit.zip

I think I've managed to do a proper build, please try @devisbal .

If it works, I'll do more official release v0.3.1 a bit later + instructions how to build.

devisbal commented 2 months ago

Hi:

It did start. But you have configured it to connect to Global Discovery. I did not see any transfer. We do use defined direct connection to the SyncThing Server. [IP:port] We do not have a Discover Server either. Info output for the test. Test.txt

I would like to start reviewing source and analyze to provide changes, but I will need that you help me with the cross compiler that you are using. I have not been able to create it.

Also, when I did try conan on a linux sysmtem with the i686-mingw , when trying conan to process zlib, I did got errors about using m-m64, and not working.

BR

basiliscos commented 2 months ago

We do use defined direct connection to the SyncThing Server. [IP:port] We do not have a Discover Server either.

This is correct sync-spirit behavior, as the "direct discovery" feature not implemented , please file a separate issue. Only relay/global/local discoveries work.

However, you can take the device id and ip address from sync-spirit and copy it to other client... and it will connect to syncthing and the sync should start.

basiliscos commented 2 months ago

I would like to start reviewing source and analyze to provide changes, but I will need that you help me with the cross compiler that you are using. I have not been able to create it.

Sure, here are the steps

  1. install conan2 (i.e. via pip install conan)
  2. download and build mxe
  3. make sure in it's settings.mk you have
MXE_TARGETS := i686-w64-mingw32.static
MXE_PLUGIN_DIRS=plugins/windows-xp
  1. make sure that everything works, e.g. something like make lua, and copy lua.exe to your win-xp host and check that it launches.
  2. add to your $PATH path to mxe/bin, i.e. i686-w64-mingw32.static-gcc should be found
  3. created xp conan profile at ~/.conan2/profiles/xp xp.txt
  4. now it should be able to pull & build all dependencies
cd syncspirit
mkdir build.xp
cd build.xp
conan install --build=missing -o '*:shared=False' -o shared=False --output-folder . -s build_type=Release --profile:build=default --profile:host=xp ..
  1. now it should sync-spirit can be configured & build
source ./conanbuild.sh
cmake .. -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE=$PWD/conan_toolchain.cmake -DCMAKE_POLICY_DEFAULT_CMP0091=NEW -DCMAKE_BUILD_TYPE=Release  -DCMAKE_CXX_FLAGS="-D_WIN32_WINNT=0x0501"
make -j`nproc`

PS. I've created wixp-support branch with yet not committed changes to let it build.

devisbal commented 2 months ago

Hi: Question: What Linux version do you use for building the WinXP version? BR

basiliscos commented 2 months ago

Question: What Linux version do you use for building the WinXP version?

it does not matter, any modern should be ok. I use void-linux :)

devisbal commented 2 months ago

Hi:

I did try on ubuntu and also void-linux. On both I got the same error when trying to generate gtk3 error at gtk3.txt BR

basiliscos commented 2 months ago

Which command did you issued and in which dir? It seems you are trying just to do make for the whole mxe...

basiliscos commented 2 months ago

make lua should be enough.

basiliscos commented 2 months ago

I've made a v.0.3.1 release. Basically it is the same as the attached exe here. Also building instructions have been updated (basically the same as here).

WBR

devisbal commented 2 months ago

Hi:

I finally believe I was able to generate it. But I got the following error.

[E/2868] ssdp, udp socket cancellation : The attempted operation is not supported for the type of object referenced

BR error-ssdp.txt

devisbal commented 2 months ago

Hi:

I did use the one on your site and that do not generate the error. [syncspirit-daemon_v0.3.1_i686-win32.zip] Did you use the wixp-support branch?

xp-ok.txt

BR

devisbal commented 2 months ago

Hi:

I just rebuild with the new instruction sequence from master, and it did work.

Thanks BR

basiliscos commented 2 months ago

[E/2868] ssdp, udp socket cancellation : The attempted operation is not supported for the type of object referenced

BOOST_ASIO_ENABLE_CANCELIO=1 that thing does the job right :)

devisbal commented 2 months ago

Hi: I build a lab with my own "discovery server". Plus: One linux syngthing and one windows syncspirit. Now the problem I nned to resolve is with the synxspirit and the entry for add_folder:label=Test:id=Test:path=M:/Test I have a disk M: om Windows where I want it to do the work, but instead it is using the path for where syncspirit is installed, creating a folder M I'm doing something worng? What should I have to use to got the use of disk M:

BR

basiliscos commented 2 months ago

Hi,

I think there was a bug that dir scanning wasn't triggered. I fixed that in v0.3.2, please try. Also I specified path at Z:\\test, you can also try z:\test and other variants with normal slash.

devisbal commented 1 month ago

Hi,

I did try all combinations: M;\Test M:\Test M:/Test M://Test and always all ended bad in SyncSpirit/M It's started with: syncspirit-daemon --log_level debug --config_dir=D:/SyncSpirit/Data --command add_peer:ub22syncthing:CL76FF7-JN2UIZN-ZKVV6SZ-FYKFNH3-VMGUSD5-RZUPOHY-WUKP4P2-44FOVQ5 --command add_folder:label=Test:id=Test:path=M:/Test --command share:folder=Test:device=CL76FF7 --command inactivate:120

[2024-05-11 22:11:17.969] [I/268] starting syncspirit v0.3.2, libraries: protobuf v3.21.9, lz4: v1.9.4, OpenSSL OpenSSL 1.1.1s 1 Nov 2022 ... [2024-05-11 22:11:19.094] [D/268] controller/CL76FF7, next_file = test.txt [2024-05-11 22:11:19.094] [D/268] CL76FF7/tcp/10.2.0.185:22000, read_controlled, std::unique_ptr<syncspirit::proto::Resp onse, std::default_delete > [2024-05-11 22:11:19.094] [I/332] fs::file_actor, file M\test.txt (2351 bytes) is now locally available

Where the other paths like --config-dir did works.

basiliscos commented 1 month ago

Oh, it was windows-specific bug in my code, as it parsed : as parameters separator. Now it should be fixed, please try v0.3.3

devisbal commented 1 month ago

Hi,

Yas, it's working now. Files did go to M:\Test Now what is happening is if I do restart syncspirit now got: [C/3680] conflict handling is not available for = Test/test.txt, 'cf156ab6c11aee0b:0' vs '12ffe297e96ea88c:1714788860'

Also: Also I think that the DB at: \SyncSpirit\Data\mbdx-db do not get clered after a file that was deleted from origen syncspitit beleive they should get it again.

[D/2332] controller/CL76FF7, next_file = Live.mp4

[I/1896] fs::file_actor, file M:/Test\Live.mp4 (29997118 bytes) is now locally available [D/3476] CL76FF7/tcp/10.2.0.185:22000, read_controlled, std::unique_ptr<syncspirit::proto::IndexUpdate, std::defau lt_delete > [D/3476] controller/CL76FF7, on_message (IndexUpdate), folder = Test, files = 1 [I/3476] net::db, committing tx [D/3476] controller/CL76FF7, next_file = Live.mp4 [D/1896] fs::file_actor removing M:/Test\Live.mp4

On the SyncThing site, it apears as requesting the file with Syncing 0Bytes ans looking at Out of Sync Item, the Live.mp4 is there.

Restarted syncspirit and got: [C/2516] conflict handling is not available for = Test/Live.mp4, '12ffe297e96ea88c:1715548576, cf156ab6c11aee0b:17 15548577' vs '12ffe297e96ea88c:1715548657'

basiliscos commented 1 month ago

this is expected behavior: when you delete a file on one device, and modify it on another, and then try to sync them, the 1st device does not knows what to do. It is a conflict, and it have to be resolved manually.

The same conflict situation is on syncthing. There are a few strategies to handle them: either push-only (i.e. ignore remote deletes/changes) changes or pull-only changes (i.e. ignore local deletes/changes), or make a conflict file for manual conflict resolution (default)

Neither of them is currently implemented in syncspirit, this is for future development.