Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IPFS Files API #37

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from
Draft

IPFS Files API #37

wants to merge 3 commits into from

Conversation

djdv
Copy link
Owner

@djdv djdv commented Jul 13, 2023

Closes: #14
This needs a lot more testing, and is lacking some fs.FS extensions. But seems to work well enough to push a draft.
Demonstration of the current state: https://www.youtube.com/watch?v=KRK8P2NVCFE

The filesystem ID chosen "ipfsfiles" is very likely to change to at least "ipfs-files". I don't know what else to call it.
Calling it "files" seems too general to reserve right now, and we can't call it "MFS" since this is simply a specific CID on the IPFS node which happens to use MFS, it is not MFS itself.
We have a separate implementation of MFS that operates on arbitrary CIDs using its own library which will likely take the ID of "MFS" later if that seems useful to have.

Example invocation:
fs mount fuse ipfsfiles $mountpoint

ctx context.Context
cancel context.CancelFunc
shell *shell.Shell
mountTime *time.Time // Substitute for mtime (no data in UFSv1).
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is going to confuse some programs when they modify the file and the timestamp does not change.
We should instead have a unique time value for open files, which gets updated on the usual events (like write, etc.).

Using time.Now isn't usually a good option for the opposite reason, programs will think a file has always been modified. This causes some tight reload loops in various programs that monitor for this.

Comment on lines +365 to +368
// TODO: I think the upstream package needs a patch to handle this internally.
// we'll hack around it for now. Investigate later.
// (When trying to use a unix socket for the IPFS maddr
// the client returned from httpapi.NewAPI will complain on requests - forgot to copy the error lol)
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This (now) only applies to the new API, not the old one.
(This workaround was originally written sometime in 2018, and a fix was incorporated upstream sometime in 2020.)

I've filed an issue upstream along with a patch for the new API so that we can remove the workaround for both IPFS APIs.
(Dropping the workaround in this patchset can be done now though since we're using the old IPFS API that has the fix.)

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

Successfully merging this pull request may close these issues.

mount: support IPFS' MFS
1 participant