ipfs-webui

ipfs-webui copied to clipboard

How do I transfer storage from C: to any other disk. Apparently even after deleting the hosted files from IPFS Desktop, the storage in C drive doesn't get removed.

So is there a way to change where I host the files?

Right now, deleting from the UI makes the blocks available for garbage collection, but doesn't trigger garbage collection. You can do so manually by running ipfs repo gc from the commmand line which will remove all the blocks that comprise the files you deleted from the UI.

This is less than ideal. We should consider triggering a GC when the user deletes a file.

@lidel can i get your opinion here? I think triggering a GC would be a simple step to making this less suprising.

A fancier solution would be to introduce a notion of a trash folder, and have deleting things just mean moving them to that folder, and then provide an "empty trash" button that deletes everything in the trash folder and then runs a GC... but I'm not convinced we need that today.

@olizilla I don't like the idea of running the GC every time the user deletes a file. It might get slow if the repository is big I think.

But I think we could have a way in the interface to run the GC.

Ok, we could grab the list of CIDs for the file and remove them explicitly. Feels like a delete should remove the file altogether. It's not possible for us to restore the file with the current code, so it's weird for the user to delete a thing but have it still take up space.

🗑 🤗

@ericronne is that a vote for a trash folder ?

Would love to test that notion with users. Fully embracing the "garbage" metaphor that we've already established.

What if:

• We add a button on Settings page to enable user to manually "Free up space by removing unused blocks from local cache" (unused sounds better than "unpinned" and works better with MFS vs cache abstraction)
• Add option to Delete dialog window that lets user to "Immediately remove unused blocks from local cache", should be less prominent, eg:

  

  • If we don't do fancy lookup&drop of blocks related to the file and always trigger global GC, perhaps this could be simplified to something like "Delete and compact cache"

dont auto trigger gc not only its quite long and io heavy slowing machine, it will delete too much data.

I like current behavior. If we are bellow GC size limit we are okay on diskspace and no point in trying to do stuff to save space.

Ack, We decided to not touch GC until go-ipfs provides improved GC with a command to run GC check over a specific DAG behind a CID (instead of full repo): ipfs repo gc --cid=<cid>

Ref. https://github.com/protocol/web3-dev-team/pull/8

This will not be fast too. you need first to build recrusive list of all cids from pin roots and then start travrl your cid to be deleted and delete only parts if referenced blocks frm your cid are not referenced from pins too.

building these lists takes a long time unless you have small repo.