Quote from: zoltanb on November 13, 2017, 10:51:22 AM

Quote from: Lyddite on November 13, 2017, 08:59:22 AM

Quote from: Kogs on September 21, 2017, 05:09:17 AM

Quote from: ScripterRon on September 20, 2017, 10:41:00 PM

Quote from: Kogs on September 20, 2017, 03:49:37 PM

Ok, understood. You use symlinks directly to the files, not to the whole directory. Makes sense, I haven't thought about this.

And thanks for describing the way to split the chain after the fork.
Just in the case someone download a complete new version of the blockchain, it might get tricky to find the correct last common data file as all files would have more or less the same time stamp (+/- 1 or 2 days, depends on download and validation speed).

That's true. I think stopping at blk00925.dat and rev00925.dat would be safe. They were last updated on 7/6/2017 on my system. There will be some variation in the .dat files depending on the number of orphan blocks encountered, but that should be early enough that all blocks would be before the split.

Can confirm, blk0925.dat has also been last updated on 7/6/2017 on my system.

Some helpful info here. Thanks!

Wish I thought about using symlinks earlier. :-) I ended up setting up btrfs and using

Code:

cp --reflink=always /home/bitcoind/.bitcoin/blocks/blk* /home/bitcoinabc/.bitcoin/blocks/

Getting more experience with copy on write filesystems doesn't hurt.

I am not sure exactly what do you do with the above command?

Basically, if using a filesystem that supports copy-on-write... the file system uses the same file for the files in both places (like a symlink, without using more space except for metadata) until one of the files is changed. When one of the files is changed a new copy could be made or the difference between the files could be stored depending on the filesystem or settings.