From @satra on Sun Mar 12 2017 16:58:59 GMT+0000 (UTC)
Can i mount a directory containing executables on an ipfs fuse mount?
for example do:
ipfs daemon &
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.
Copied from original issue: https://github.com/ipfs/faq/issues/235
From @Kubuxu on Sun Mar 12 2017 17:32:24 GMT+0000 (UTC)
No, the executable flag won’t be set on this file. Not sure how to work around it to be able to call
From @satra on Sun Mar 12 2017 17:52:30 GMT+0000 (UTC)
@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.)
From @lidel on Sun Mar 12 2017 20:06:37 GMT+0000 (UTC)
@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.
From @satra on Sun Mar 12 2017 20:19:47 GMT+0000 (UTC)
@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
which, but the actual bits would be transferred only when open is called on the file descriptor whether via exec or read/write.
From @whyrusleeping on Sun Mar 12 2017 22:09:08 GMT+0000 (UTC)
Supporting executable bits is definitely on our todo list.
From @lidel on Sun Mar 12 2017 23:01:47 GMT+0000 (UTC)
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)
From @satra on Wed Mar 15 2017 17:19:15 GMT+0000 (UTC)
@lidel - thanks i’ll look into this.
my hope was for lazy execution.
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.