-
Notifications
You must be signed in to change notification settings - Fork 2
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
base: master
Are you sure you want to change the base?
IPFS Files API #37
Conversation
ctx context.Context | ||
cancel context.CancelFunc | ||
shell *shell.Shell | ||
mountTime *time.Time // Substitute for mtime (no data in UFSv1). |
There was a problem hiding this comment.
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.
// 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) |
There was a problem hiding this comment.
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.)
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