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

Symlinks #52

Closed
wants to merge 3 commits into from
Closed

Symlinks #52

wants to merge 3 commits into from

Conversation

matheus23
Copy link
Member

Closes #24

📜 Preview

TODO:

  • How would you import relative unix symlinks into WNFS? In public WNFS we already have a path, so it's fairly straight-forward to support, in private WNFS though? Would it not refer to an inumber?

@cla-bot cla-bot bot added the cla-signed label Dec 1, 2022
@matheus23 matheus23 self-assigned this Dec 1, 2022
type PrivateSymlink = {
type: "wnfs/sym/priv"
root?: string
inumber: Inumber

Choose a reason for hiding this comment

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

dumb q alert: guessing this Inumber is always unique (after looking at the current code too)? Do we have anything like an Inode for filesystems in wnfs? https://en.wikipedia.org/wiki/Inode.

Copy link
Member Author

@matheus23 matheus23 Dec 13, 2022

Choose a reason for hiding this comment

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

Yes, this number should be unique (unless there's a malicious peer with write permissions or a buggy implementation). You could think of files and directories at inodes. The term inumber also appears in the linked articles. It would then be the number that refers to a certain inode.
However, in our case the inumber is persistent across revisions. This is where the analogy kind-of breaks down. I'm not super sure whether inumbers change between revisions in traditional file systems, or whether everything basically happens via in-place mutation.

- They enable linking out to other user's file systems from your own file system
- They enable linking between public and private parts of file systems

While hard links (`CID`s or private references) conceptually are supposed to work like 'copying' the linked data, a symlink is meant to work differently:

Choose a reason for hiding this comment

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

code-wise, do you see any aliasing needed for hardlinks now (vs symlinks)?

Copy link
Member Author

Choose a reason for hiding this comment

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

No. I don't think so.

I'm still thinking idly about the symlinking stuff in WNFS.
Only in the public file system hard-links correspond directly to CIDs.
In the private file system, that's not quite the case.

If our "own" version of hard-links doesn't become a thing, this will probably be a comment on the cp function of the public file system, as it doesn't actually need to copy anything, it's similar to a hard link.

@matheus23
Copy link
Member Author

matheus23 commented Jul 18, 2023

Closing this for now, as I don't intend to work on a spec in the near future.
The problems is mainly that there's a tug-of-war happening with symlinks where there's three different use-cases that I fear all warrant slightly different solutions:

  • Deduplication (on the decrypted level)
  • Key management (e.g. collecting access to all of the directories and files that were 'shared with you' from other users in a central place)
  • POSIX file system round-tripping. I.e. injesting POSIX symlinks as WNFS and being able to output them again.

I will reopen this once we figured out a plan/prioritization for some of these things.

@matheus23 matheus23 closed this Jul 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Symlink Spec
2 participants