Skip to content
This repository has been archived by the owner on Apr 29, 2020. It is now read-only.

fuse mount, executable path on linux #235

Closed
satra opened this issue Mar 12, 2017 · 8 comments
Closed

fuse mount, executable path on linux #235

satra opened this issue Mar 12, 2017 · 8 comments

Comments

@satra
Copy link

satra commented Mar 12, 2017

Can i mount a directory containing executables on an ipfs fuse mount?

for example do:

ipfs daemon &
ipfs mount
export PATH=/ipfs/QmWvQ8fz9XMJoxQHV5BHKmVqYoVNWkckUxQ8LNSgEkdBgD/bin:$PATH

# or

export PKG_HOME=/ipfs/QmWvQ8fz9XMJoxQHV5BHKmVqYoVNWkckUxQ8LNSgEkdBgD/
source $PKG_HOME/setup.sh

ps. i can't seem to get this to work inside my current environment. i'm going to check it on a remote machine to test.

@Kubuxu
Copy link

Kubuxu commented Mar 12, 2017

No, the executable flag won't be set on this file. Not sure how to work around it to be able to call source.

@satra
Copy link
Author

satra commented Mar 12, 2017

@Kubuxu - thank you. it would be interesting to see if fuse could contain executable information. i've been able to do this with s3fs in the past i believe.

(it seems i have a bigger problem right now - i can't even do an ipfs ls on a directory hash on two separate machines on two different networks.)

@lidel
Copy link

lidel commented Mar 12, 2017

@satra As a workaround, you can wrap your data with EncFS or create a file with encrypted loop device using dm-crypt and luks. Both enable you to set executable flag inside of encrypted filesystem.

If you don't care about encryption, just create a file with loop device alone.

@satra
Copy link
Author

satra commented Mar 12, 2017

@lidel - thanks for the suggestion. a key point here about mounting the ipfs directory hash is to minimize the data transferred to just the bits needed for that particular execution. wouldn't a loop device or encfs require all the bits of the file to be transferred to the host?

ideally we would just have the metadata transferred so that people can do things like ls, which, but the actual bits would be transferred only when open is called on the file descriptor whether via exec or read/write.

@whyrusleeping
Copy link

Supporting executable bits is definitely on our todo list.

@lidel
Copy link

lidel commented Mar 12, 2017

@satra until go-ipfs provides native support for executable bits, you can try to mitigate the need for big downloads by creating separate loop device per every executable (yes, it is an overkill, but should be easy to orchestrate with shell scripts)

@satra
Copy link
Author

satra commented Mar 15, 2017

@lidel - thanks i'll look into this.

my hope was for lazy execution.

ipfs mount
export PATH=/ipfs/some_location/:$PATH
executable_on_ipfs_path arg1 arg2 

so initially executable is not on the system, but will be pulled by a trigger from the system path check by the fuse endpoint.

@flyingzumwalt
Copy link
Contributor

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants