Windows

[cryptix]

To compile on windows, you need to disable fuse by compiling with go build -tags nofuse.

There are a number of other outstanding issues:

• [x] update go-reuseport to get windows compilation (#958)
• [x] when build for windows, github.com/cheggaaa/pb depends on github.com/olekukonko/ts which is currently not vendored
• [ ] shutdown sometimes leaves daemon.lock sitting around and spits out ERROR ipnsfs <autogenerated>:24: leveldb: closed
• [ ] sometimes blockservice.test.exe or dht.test.exe hang during go test -tags nofuse ./... and need to be killed manually
• [ ] some test failures- runs: 1 2
• [ ] some weird inconsistency between running in cmd.exe and bash.exe from git for windows

And I'm sure there is more. My tests are from a windows 7 QemuVM with a flacky VDE/SlirpDHCP network. I welcome every native windows user willing to test this with open arms.

[jbenet]

Update on this issue?

I believe some users have gotten it working on Windows. Would be good to have a link to point users to.

[ghost]

Ping again. I can run ipfs in a small VM but it's a little RAM hungry for any of my embedded boxes.

[jbenet]

cc @gatesvp

[cryptix]

I did a quick test just now..

cmd/ipfs still compiles. It also inits, daemon serves the webui and connects to peers but there are a couple of issues with the tests (only tested go tests.. didn't install make yet) so I think it needs some work.

Some recap of the still open points:

1) The vendoring issue of github.com/olekukonko/ts is still on the table Done

I'm not sure how to proceed with it. If we add it Godeps.json manually, we basically can't touch it with (current) tools anymore..

2) daemon shutdown also still seems to be icky

3) test runs of blockservice and routing/dht (hint: still failing.. :disappointed: )

4) some curious test fails

• commands/cli
• core/...
• and another run of (./..) for completeness

I already told @whyrusleeping about a small problem with iptb.

# github.com/ipfs/go-ipfs/Godeps/_workspace/src/github.com/whyrusleeping/iptb
C:\Users\hbpunkt\go\src\github.com\ipfs\go-ipfs\Godeps\_workspace\src\github.com\whyrusleeping\iptb\main.go:243: unknown syscall.SysProcAttr field 'Setsid' in struct literal

All this said, I used current master to exfiltrate these logs, so it can't be that far-off. I'd like to hear from somebody with a proper shell setup, that can run the sharness tests.

[ghost]

@cryptix Thanks for the update - what do you mean by a "proper shell"?

[cryptix]

what do you mean by a "proper shell"?

Just a sysetm that can run our sharness tests. :)

[ghost]

I think I can make it work in msys2. Perhaps a future goal should be a cross platform test harness?

[whyrusleeping]

@cryptix

The vendoring issue of github.com/olekukonko/ts is still on the table

Just add it to util/sadhack/godeps.go

[cryptix]

right, that would work for the availability. What bugs mit is that godeps doesn't rewrite import paths for other OSes. (By default, I havn't check if it respects GOOS env var)

[gatesvp]

In the air on this one from the Windows perspective. I actually really like the idea, but windows has two commonly-used "shells": cmd and PowerShell.

cmd has been around forever, but PowerShell is more powerful and available on everything Windows 7 & up. I point out PowerShell because it actually has things like ls and cat correctly aliased. Most of the sharness tests could likely run in PowerShell with no changes at all. In fact, I'm going to have to give this a try :)

[alexpmorris]

I believe the ImDisk API could be used to provide a fuse-like interface to ipfs on Windows systems via a DLL, which should be accessible in golang.

ImDisk Virtual Disk Driver API http://www.ltr-data.se/library/ImDiskNet/html/b172f3e5-9b16-6bf0-6b60-33666abb4aec.htm

Here is the overview from http://www.ltr-data.se/opencode.html :

Source code for all of ImDisk, including a server-part for nix like systems and .NET/COM API library, is available as a 7-zip compressed file here (191.3 KB), source for beta version 2.0.0 available here (220.8 KB). The Windows driver, command line tool and Control Panel applet parts of the source code can be built in the Windows 2000 build environment in the latest WDK and the nix parts can be built with for example gcc. .NET components are built in Visual Studio 2010, you can use Visual Basic Express 2010 if you want to view and modify the source code in a free version of Visual Studio. API

API functions are available for C/C++, COM and .NET clients. If you want to call functions for creating/removing/querying virtual disks from your own program you can #include the file inc\imdisk.h in your C/C++ source files and link the cpl\i386\imdisk.lib library. Read inc\imdisk.h in source archive for documentation about C/C++ usage. If you would like information about how to write compatible server-end software in C/C++ you can take a look at the I/O packet structures in inc\imdproxy.h.

A class library DLL for COM and .NET developers is available as a separate wrapper DLL. You can download that DLL here or an archive including the actual DLL along with import libraries and registry files for COM usage here. Look here for on-line documentation about .NET API. There are also, as usual, xml files with method/parameter descriptions available to each assembly file.

[jbenet]

@alexpmorris thanks sounds promising. want to take a stab at it?

[ghost]

The dokany fork is also worth a look.

[cryptix]

Ah, nice! thanks for digging that up.

I faintly remember a sshfs fork for windows, I think it used that API as well(?)

[ghost]

Yep, sshfs is one of the dokan examples. I think dokany has an updated version of that.

[alexpmorris]

I messed around with this a bunch. ImDisk/DevIO turns out way too low-level for this as it's more geared towards block devices. Dokan could definitely work, but it's tricky to convert the headers for use in go. Perhaps I'm missing something simple, but I tried using cgo, swig, def2go, etc, and got nowhere. I did come across a repo doing just this, but it's still a long way off from working fully:

https://github.com/raff/dokango - A Go interface to dokan

I tried installing dokany but it doesn't work on older Windows systems, so I played around with this version that did work for me (from the sshfs fork a few people mentioned):

https://code.google.com/p/win-sshfs/

[ghost]

Hey @alexpmorris, is there any way I can help you get on a later Windows version? Perhaps Win10 in a VM/VHD would do?

[alexpmorris]

I have a basic working implementation of this. However, it's in Delphi/FreePascal, not go. The trickiest part was that Dokan needs the correct file size in GetFileInformation, so I step up the path until I find it. Dokan uses that information to repeatedly call the ReadFile method with a 512 byte buffer until it has the total bytes it expects.

Just a few thoughts... The file sizes are larger than the actual content. At first I thought the overhead was 11 bytes, but then other files/blocks had only 8. Perhaps there is some way I missed to figure out the exact size. It would have been also useful if a request such as this would return size:

http://127.0.0.1:5001/api/v0/ls?arg=/ipfs/QmRCJXG7HSmprrYwDrK1GctXHgbV7EYpVcJPQPwevoQuqF/test/bar

I hope others find this useful, and it should also make it easier to build a version in go if there is sufficient demand for it.

Lastly, I'm not sure this will work on newer Windows systems, but you are free to try, and it shouldn't be that difficult to get it to work there too. I'll try myself too when I get a chance.

Here is the link, the executable version is under releases:

https://github.com/alexpmorris/dipfs

[whyrusleeping]

@alexpmorris i've gotten a few requests for an API to get the exact size of a file, and as far as I know, we dont have that yet. I can write it up today and let you know when its done

[alexpmorris]

I tested dipfs on a 64-bit Windows7 system with the same version of Dokan included in the repo, and it worked perfectly! So it should work on 32-bit and 64-bit Windows at least up to Windows7 (so far). I also released a slight update.

[alexpmorris]

dipfs also works with the latest dokany release, which has been confirmed to work up to Windows 10.

[whyrusleeping]

I'm going to go ahead and close this issue.

Further discussion of dokany windows can and should go into a new issue (either on this repo or on the dipfs repo).

Further discussion of problems with running ipfs on windows should open a new issue for each problem encountered.