In my case I need to preserve symlinks as a references not replaced by a file content itself. It’s required by a browser runtime: JS files after reading from the hard drive have state and missing of symlinks make the environment to reinitialize a new state. While I can simulate required behavior with an additional file with symlinks layouts, it looks like a hack and I’m wondering if symlinks will are going to be a part of IPFS. If it’s not then I wish to propose such ability.
unixfs v2 is being worked on now, and while it’s not final, many of the documents make reference to supporting symlinks e.g.: https://github.com/ipld/specs/blob/7228a1a1538faa440dc8f0df63a661e30022107d/design/history/exploration-reports/2019.06-unixfsv2-spike-01.md#schema
There is also dicusssion of inlining small files, in to the document which is effectively a directory listing, this would mean symlinks could be reproduced accurately in the filesystem APIs and any real filesystem exporting, but that they should still load as quickly as a file which is effectively “hard linked” by having two entries pointing to the same CID hash, how links generally work on IPFS filesystems today in unixfs v1.
So I think you will get this feature in a future version. unixfs v1 is difficult to change because it is built with protobufs, so it is hard to add new features like this. Core devs seem to be focused on upgrading the filesystem representation with a more flexible format and pushing new features to that to avoid wasting a lot of time and effort trying to introduce them to the unixfs v1 format. Improvements to filesystem capabilities should be faster and easier once unixfs v2 is released.
Thanks for detailed explanation. Is there any well-known/semi-standard solution to implement symlinks over v1 (even with a performance penalty)?
As far as I’m aware, unixfs v1 doesn’t support symlinks at all. The only thing i can think of, is to use an archive format like .zip or .tar, which might be acceptable if you need to download the whole structure anyway and don’t need to lazy load pieces of it as needed (though range requests are technically possible over IPFS and the IPFS http gateway does support them, so it is possible to stream out parts of files as needed and maybe possible to hook a tar library up to a tar file on unixfs v1, but i wouldn’t expect it to be fast in that lazy loading scenario)