Recovery after failed move of .ipfs on Desktop

after a warning message (???) re “couldn’t pin…” or something like that, i can no longer access my Files folders again.

Tried restart IPFS, restart Windows 10 but couldn’t resolve the issue.

The IPFS Desktop is installed on my c:\ and data on d:\

I’ve about 20Gb of data.

Tried to upload a screen of the Files directory but the upload was rejected

I’m sorry if i shouldn’t ask another question not related to this topic.

Right after i saw a message about pinning (the message just flash & gone), i can no longer access my file directory (see attached screenshot). i’ve a habit to pin all my files stored on my local node, it this necessary?

My IPFS Desktop is installed on my Windows 10 machine on c:\ (which is a SSD card), and my data is stored on d:\

Few days ago i moved my .ipfs directory from c:\ to d:, a HDD, then everything went down.

Now i’m trying to rebuild everything from scratch on my d:\ and things are not so smooth as before.

So frustrating!!!

Interesting, need more information:

  • What type of drive is D:\? A physical HDD or some network NAS/SMB resource?
  • What was the size of your .ipfs?
  • How did you move your .ipfs? Using “Move Respository Location” option from the tray menu or by some other means?
  • Are you able to execute ipfs files ls / on the command line? What is the output?
  • D:\ is my local HDD attached to my desktop
  • the one on d:\ is about 20Gb
  • i made a stupid move just copy & paste from c:\ to d:\ few days ago (based on info written on ipfs.io)
  • no output (see below)

C:\Users\User>ipfs files ls

C:\Users\User>

Microsoft Windows [Version 10.0.19042.1526]
(c) Microsoft Corporation. All rights reserved.

C:\Users\User>ipfs daemon
Initializing daemon…
go-ipfs version: 0.11.0
Repo version: 11
System version: amd64/windows
Golang version: go1.16.12
Swarm listening on /ip4/127.0.0.1/tcp/4001
Swarm listening on /ip4/169.254.17.152/tcp/4001
Swarm listening on /ip4/169.254.18.158/tcp/4001
Swarm listening on /ip4/169.254.18.82/tcp/4001
Swarm listening on /ip4/169.254.99.33/tcp/4001
Swarm listening on /ip4/223.16.245.119/tcp/4001
Swarm listening on /ip6/::1/tcp/4001
Swarm listening on /p2p-circuit
Swarm announcing /ip4/127.0.0.1/tcp/4001
Swarm announcing /ip4/223.16.245.119/tcp/4001
Swarm announcing /ip6/::1/tcp/4001

Error: serveHTTPApi: manet.Listen(/ip4/127.0.0.1/tcp/5001) failed: listen tcp4 127.0.0.1:5001: bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.

C:\Users\User>

++++++++++++++++ +++++++++

Here’s more info maybe it’ll help!

it might be helpful to you to solve the problem. Below is the error message that appeared prior to the problem.
Unable to set pinning. Try again, or see the browser console for more info

Thanks for the info. I think it boils down to this:

No wonder things broke.
Do you remember the URL with the info that made you think that is ok? (It is not, we should fix the docs).

ipfs://bafybeibl7hi36shoon3mumzmghfopjqbczn7c6pmb7rcksajaxz672uvmm/how-to/move-ipfs-installation/#move-installation

ipfs://bafybeibl7hi36shoon3mumzmghfopjqbczn7c6pmb7rcksajaxz672uvmm/how-to/move-ipfs-installation/#windows

i use IPFS Companion on my Brave browser now

Is my data stored on c:\ (which is a SSD)? i want to move it to my HDD, is it possible?

Thank you for the links, I filled a bug against our docs: Move an IPFS installation: Desktop vs CLI sections · Issue #1033 · ipfs/ipfs-docs · GitHub – they are written for standalone daemon and CLI, and do not work with IPFS Desktop.


Manual fix for IPFS Desktop .ipfs move

If you still have the old IPFS Desktop repo intact, you can try to revive it by manually pointing IPFS Desktop at the new .ipfs location by editing config.json of the Desktop app and updating value in ipfsConfigpath field to point at the new location.

On Windows it should be located at C:/Windows/Users/$user/AppData/Roaming/IPFS Desktop/config.json

Alternative symlink fix

A different approach to moving repo: create a symlink in the original location pointing at the new one. This way no configuration has to be changed – tools and apps like IPFS Desktop should think nothing changed.

I know Windows 10+ supports symlinks, and those should work across drives, but you’d have to learn the details yourself (not a Windows user myself).

Brave

Brave stores data in your browser profile.
I don’t believe moving repo location is offically supported by Brave, but you could try the symlink trick.

Since i’ve been uploading many files in the last few days, is there a way to consolidate all these “blocks” of data together?

E.g. adding more directories in the “path”: “D:\.ipfs”, …

If you are comfortable with command-line, you could set IPFS_PATH to point at specific repository on your disk and migrate your data that way.

Below are commands from Linux, most likely you’d have to tweak them to work on Windows.

Import/export .car file with all the data

CAR import/export is quite flexible, as it can be performed when your nodes are online or offline.

  1. Export all “Files” from your old node to a .car file:
$ export IPFS_PATH=/path/to/OLD/.ipfs
$ ipfs files stat / 
(the first line will have root CID with all your "Files")

$ ipfs dag export CID >  files.car
  1. Then on the new repo/node import the .car and put everything under /old-files directory in “Files” :
$ export IPFS_PATH=/path/to/NEW/.ipfs
$ ipfs dag import files.car
$ ipfs files cp /ipfs/CID /old-files-dir
$ ipfs pin rm CID 

( remove low level pin at the end because MFS aka “Files” will already protect data from GC, and you most likely don’t want the data removed from “Files” to be stuck in your cache)

Streaming CAR without touching the disk

Alternatively, if you have two nodes running you could use ipfs --api to point at specific ones, and even pipe the data so there is no .car written to the disk.

For example, to migrate everything from Brave to IPFS Desktop (assuming default RPC API ports:

$ ipfs --api /ip4/127.0.0.1/tcp/45001 dag export CID |  ipfs --api /ip4/127.0.0.1/tcp/5001 dag import 
$ ipfs --api /ip4/127.0.0.1/tcp/5001  files cp /ipfs/CID /old-files-dir
$ ipfs --api /ip4/127.0.0.1/tcp/5001  pin rm CID 

ipfs files stat / produces the following result
D:.ipfs-desktop 3.7Gb>ipfs files stat /
QmUNLLsPACCz1vLxQVkXqqLX5R1X345qqfHbsf67hvA3Nn
Size: 0
CumulativeSize: 4
ChildBlocks: 0
Type: directory

ipfs dag export
D:.ipfs-desktop 3.7Gb>ipfs dag export QmUNLLsPACCz1vLxQVkXqqLX5R1X345qqfHbsf67hvA3Nn
0s 0 B / ? [-------------------------------------------------------------------------------------------------------=]8�eroots��*X# :arrow_up_down: Y��9​:spades:_)a��:arrow_up_down:�˹2�R�m�Ŗke�◄:arrow_up_down:9����gversion​:relaxed:&:arrow_up_down: Y��9​:spades:_)a��:arrow_up_down:�˹2�R�m�Ŗke�◄:arrow_up_down:9����
0s 96 B / ? [---------------------------------------------------------------------------------=------] 2.60 KiB/s 0s

Tried import another CID from IPFS Desktop and produced the following:

D:.ipfs-desktop 3.7Gb>ipfs dag export QmZkBTNQvHuoGwyjvgkK5arPXugPDxPNioRxMhr9vtL7ro
0s 0 B / ? [-------------------------------------------------------------------------------------------------------=]8�eroots��*X# :arrow_up_down: �w�����6#����d ���١�&�g↨��]�:slight_smile:��gversion​:relaxed:Error: merkledag: not found (currently offline, perhaps retry after attaching to the network)

My IPFS Desktop was online without doubt.

I’m not sure whether i’m doing it right!!!

I am afraid you need to learn how to handle streaming to stdout on Windows if you want to use these commands.