Build on Windows?

[garyhodgson]

Hi - as already mentioned in #8 (comment) 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: bazil/fuse#5 (comment)

Windows x64, via cygwin if that is relevant.

[whyrusleeping]

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]

@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]

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:

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

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

[whyrusleeping]

@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]

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]

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

[toqueteos]

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 deuill/sleepy@4a2688e/core/server/ftp.go#L43-L117

My vote is +1 for FTP.

[verokarhu]

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<hash-of-object><name-path-to-object>.

[toqueteos]

@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]

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
#9 (comment).

[whyrusleeping]

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]

@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]

@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]

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<hash-of-object><name-path-to-object>