Build on Windows? - Githubissues

garyhodgson commented 10 years ago

Hi - as already mentioned in https://github.com/jbenet/go-ipfs/pull/8#issuecomment-49886962 it appears that the fuse project will not compile on Windows. I get the following error when attempting go get ./...:

  # bazil.org/fuse
  ..\..\..\..\..\bazil.org\fuse\fuse.go:985: undefined: attr
  ..\..\..\..\..\bazil.org\fuse\fuse_kernel.go:314: undefined: attr

This comment at the fuse project from last year seems to indicate that windows is not supported: https://github.com/bazillion/fuse/issues/5#issuecomment-24172348

Windows x64, via cygwin if that is relevant.

whyrusleeping commented 10 years ago

fuse itself doesnt actually work on windows this is because windows doesnt allow you to add filesystem entries without modifying code in the kernel. So sadly, were going to have to have to use something else to have windows support.

One possible solution for windows would be dokan, although I havent looked into it very much.

toqueteos commented 10 years ago

@whyrusleeping I'm curious is this the dokan you are talking about?

EDIT: Damn it, I missclick shift+enter.

Links: https://github.com/clone/dokan https://code.google.com/p/dokan

jbenet commented 10 years ago

I don't know how Windows handles filesystems, so I'll let others who do know discuss this (like @whyrusleeping). I think a good way fwd is to outline a series of possible things, and then either:

move readonly.go to readonly_unix.go and do whatever as readonly_windows.go conforming to the same interface
use a separate package, and wire that up in cmd/ipfs.go

For modularity, I'd prefer (1.) :)

whyrusleeping commented 10 years ago

@toqueteos that is indeed the dokan I was referring to. Like I said. i dont have any experience using it, but it appears to do what we want. There also doesnt appear to be a go binding to the library either, which presents an interesting opportunity.

toqueteos commented 10 years ago

Another option is to use a webdav server (https://github.com/gogits/webdav seems a good start) and mount that as drive on Windows, this will be properly hidden on readonly_windows.go.

Some quick googling shows promising results for this alternative.

Seems easier to implement and involves zero C code interop ~~(no win32 api calls unless we also want to add ipfs as drive programatically)~~ We could just add the drive with os/exec via untested: NET USE * http://servername/fs/ password /USER:username

EDIT: Formatting.

whyrusleeping commented 10 years ago

That sounds a lot better than my idea, im all for a pure go implementation.

toqueteos commented 10 years ago

There's also SMB (Samba) and FTP as alternatives to FUSE that can be mounted as network drive.

So we have 3 alternatives right now:

WebDAV, GoDoc, Go-Search, basically just https://github.com/gogits/webdav, which is incomplete.
SMB, GoDoc (smb), GoDoc (samba), Go-Search (smb), Go-Search (samba). No results on GoDoc, Go-Search shows some bindings for libsmbclient.
FTP, GoDoc, Go-Search, tons of libraries, most of them clients. Seems the easiest approach. There's some partial server implementations out there https://github.com/thoughtmonster/sleepy/blob/4a2688ecc3f6c87c8b160a7dfd739dc9a59afcf0/core/server/ftp.go#L43-L117 thoughtmonster/sleepy@4a2688ecc3f6c87c8b160a7dfd739dc9a59afcf0/core/server/ftp.go#L43-L117

My vote is +1 for FTP.

verokarhu commented 10 years ago

I'm curious, what is the use case for having ipfs behind a drive letter?

Since the user would not be able to "point and click" the drive open (windows needs to know what the folder structure is in order to display it to the user, which is of course impossible since ipfs is huge) to access ipfs paths, it seems pointless to expose this in the GUI. Users would also end up trying to drag & drop files directly to the mount which would also not function. It wouldn't really be useful for applications either, since they would still have to figure out which letter ipfs is mounted on.

I suggest using UNC paths which is the way network resources are supposed to be named on windows, this allows windows "users" (in the majority of cases, applications) to access ipfs through e.g. \ipfs\ and/or %IPFS% which points to the configured root. Files could still be manipulated in the command prompt since most commands support UNC paths. You could also open files in the file explorer by entering e.g. \ipfs\\.

toqueteos commented 10 years ago

@verokarhu Having all of ipfs mounted as drive of course makes no sense but something has to serve some subset of it in order to use it as network share, nobody said UNC paths shouldn't be used.

The mount to letter can be ditched of course and after experimentation it would be the best thing to do. I did implement a most of RFC 959 (FTP server) in Go and tried to use the network share as drive and it gave me lots of issues and trouble; using UNC paths instead worked just fine.

verokarhu commented 10 years ago

All right, but what do you mean by "in order to use it as network share"? Do you mean that the ipfs client should expose a GUI for dropbox- like functionality?

In that case it would be best to copy the way dropbox and gdrive do it: a special folder in the users home directory which is synced. On Jul 30, 2014 5:51 PM, "Carlos Cobo" notifications@github.com wrote:

@verokarhu https://github.com/verokarhu Having all of ipfs mounted as drive of course makes no sense but something has to serve some subset of it in order to use it as network share, nobody said UNC paths shouldn't be used.

The mount to letter can be ditched of course and after experimentation it would be the best thing to do. I did implement a most of RFC 959 (FTP server) in Go and tried to use the network share as drive and it gave me lots of issues and trouble; using UNC paths instead worked just fine.

— Reply to this email directly or view it on GitHub https://github.com/jbenet/go-ipfs/issues/9#issuecomment-50625370.

whyrusleeping commented 10 years ago

I believe if we implemented an ftp server as discussed previously, we would as a result be using unc paths like you suggested. If the user pins any files, those would be viewable in the standard file explorer.

toqueteos commented 10 years ago

@verokarhu No, I'm talking about the underlying implementation used for serve.

Non-windows OSes use fuse to mount /ipfs, what do we use for Windows?

Also as @whyrusleeping said, some sort of file explorer integration, at least for pinned objects would be ~~a nice feature~~ desirable.

verokarhu commented 10 years ago

@toqueteos Ah, misunderstood you a bit there. FTP sounds fine, especially since you apparently have a working version of that already. I was mostly worried about the drive letter mounting ideas earlier in the thread, which now seems unnecessary since you seem to already have come to the conclusion that they are a bad idea.

verokarhu commented 10 years ago

I made a pull request that should resolve this issue. Eventually the windows version of the mount command should have a different implementation, perhaps it would be used to mount ipfs behind a UNC hostname. E.g. 'ipfs mount hostname' which would enable the user to access ipfs through \hostname\\

cryptix commented 9 years ago

Hey everybody. We have the 'nofuse'-build tag to move forward. I'll close this in favor of #959.

richardschneider commented 7 years ago

I've create a project to mount IPFS/IPNS on a Windows driver letter. Its open source at https://github.com/richardschneider/net-ipfs-mount

Kubuxu commented 7 years ago

@richardschneider Incredible, thank you so much.

ipfs / kubo

Build on Windows? #9