nocopy option doesnt work without moving files (defeating part of the purpose)

[PCSmith]

Version information: 0.4.10

Type: Bug / Implementation Flaw

Severity: high

Description:

The "filestore" capability should be considered baseline for this project IMO. The expectation cant be to duplicate all bytes you want to place on IPFS by keeping a copy in the datastore... Nor can it be to expect users to throw their existing directory organisational structure out the window to manually copy IPFS candidate files to a central location.

Need the ability to --nocopy any file in any location and have that file not move or be copied anywhere. Also, if this --raw-leaves thing is needed for this it should be done by default. Not sure if it is though.

Thanks for your work on this world changing project.

[djdv]

@AzureCerulean Sorry for responding a year later, I must have missed this notification. The IPNS key format seems to have changed or something. I updated the links but that project is no longer maintained. IIRC the code for this predates any (stable) IPFS APIs so it just wraps the binary directly. This is a bad strategy that I wouldn't do now that the CoreAPI exists, but it also means that the extension likely still works. But I haven't tried it. The hashes in that post were updated though, so they should actually resolve now (when my node is online) if you're still interested in it.

Judging by the comments above, It seems like the underlying --nocopy feature itself though has regressed in some way so even if the extension works, the command itself might not :^/ But if it does and it seems useful let me know and I might rewrite it and publish the sources. The current/old version is a nasty mess of C++ and Go that communicate over my own binary protocol so it's probably easier to just rewrite it in modern C++ and communicate directly with the IPFS node over http. (The extension was never meant to be anything more than a quick hack for myself but people really liked it so I published it)

[mrambossek]

so.. apart from the patched but outdated version here https://github.com/jbarthelmes/go-filestore/commit/5a54f9a2bec2b617681f9f66bd3a204230b9225a .. is there a solution for windows users now? symlinks/hardlinks do not work for me; UNC paths obviously not either. regardless of what i do, i always get

929.25 MiB / 5.33 GiB [=============>-----------------------------------------------------------------]  17.02% 00m04s
Error: cannot add filestore references outside ipfs root (D:\ipfs)

(actual files / directory would be on e: or i:, so other drive)

[tinfever]

I'm having the same issue with the "Error: cannot add filestore references outside ipfs root" message with IPFS_PATH set. I wanted to add 600GB of files already downloaded via torrent but it appears I can't do so.

[mrambossek]

I was unable to get any help regarding this on the matrix/discord channel as well. Either devs are currently busy with other things or windows is not really a concern for them :( trying to find alternatives to ipfs now.. my main problem is that I want to have a (moderately large) tree of dirs and (rather large) files and the structure keeps changing .. if I just create, say, a torrent, this would mean a new overall torrent on every single change - a problem that ipfs supposedly has solved...

[Vort]

@mrambossek you may look at DC++ networks (AirDC++ client for example). This technology is old, but it do exactly what is needed - you specify what directory you want to share and it becomes shared.

[FryingPanBrock]

@mrambossek you may look at DC++ networks (AirDC++ client for example). This technology is old, but it do exactly what is needed - you specify what directory you want to share and it becomes shared.

But then it would not be on IPFS, thus defeating the point. People like @mrambossek and I want to share files on specifically IPFS without duplicating said files, which could potentially be very large. I hope that the IPFS developers will take this issue more seriously in the near future. It is, to me, the only reason that torrents or Direct Connect still have a use case: your 200 gigabyte torrent will not take up 400 gigabytes of space on your hard disk.

I have a dream that one day IPFS can be used like a decentralised Dropbox without hassle.

[mrambossek]

so.. came back almost a year later and retried.. still same issue... no love for windows people?

just to clarify the issue once more; on linux, you can mount --bind stuff all over the place, and solve it like that. on windows, you are very limited in that regard; you cannot create "Hard Links" or "Junctions" to, for example, network paths.

symbolic links, even though they require admin rights to create, are NOT followed by ipfs when nocopy-adding; instead, the tiny lnk files are added. the --dereference-args parameter does not help either, both because it only works for single file arguments (not directories and their respective files) and also because when i try to add a single file with it, i get the dreaded "outside of ipfs" error again.

soooo.. for me (im not a dev) the most logical approach would be to add a configuration parameter like "additional paths" where you can add an array of paths that, if the file-to-be-added is "below", allow it to proceed.... would that be as relatively easy as i think it should be or am i missing something?

[pedroapero]

I'm running Kubo on Linux in a Docker container.

I tried with symlinks, but it added a 0B file (probably the link file and not the destination).

I tried mounting the disk in $IPFS_PATH/media, and I got:

• with small files: «Error: filestore is not enabled, see https://git.io/vNItf» (although the feature is enabled)
• with big files: it stales at 1.75 MiB.

[HostFat]

Any news on this? :)

[simonhorlick]

This issue has now been open for 6 years. I'm just wondering what the blocker is here? The code change itself is trivial, but what would need to happen for that to be accepted?

[HostFat]

Is there a way to donate specifically to completely fix this issue on every OS?