recon command crashes on slice out of range

[5ay3h]

Hi @cblichmann !

I am trying to use your tool to restore a "lost cause" BTRFS partition.
I'm getting this crash while running the command recon on the image:

# identify
root@lubuntu:/tmp# /root/go/bin/btrfscue identify /mnt/wd/Backup/dell_dd/sda5_dd.img 
 2012 / 2013 [==========================================================================================]  99.95% 13s
fsid                                 count entropy  block size
91dea238-022f-4014-8863-f96ec0c657f9 42    3.875000 16384
00000000-0000-00b2-0500-000000000000 7     0.668564 0
d2b16853-89e0-4324-bd66-015325e8d48e 5     3.875000 16384
# recon
root@lubuntu:/tmp# /root/go/bin/btrfscue recon --id 91dea238-022f-4014-8863-f96ec0c657f9 --metadata metadata.91dea238-022f-4014-8863-f96ec0c657f9.1.2.db /mnt/wd/Backup/dell_dd/sda5_dd.img 
 36.27 MB / 76.80 GB [>----------------------------------------------------------------------------------]   0.05% 1s
panic: runtime error: slice bounds out of range

goroutine 1 [running]:
blichmann.eu/code/btrfscue/btrfs.Leaf.Data(0xc4200a4000, 0x1000, 0x1000, 0x0, 0x1000, 0x2444000, 0x1000)
	/root/go/src/blichmann.eu/code/btrfscue/btrfs/leaf.go:123 +0xc6
main.(*reconCommand).Run(0xc42000a3c0, 0xc42000e140, 0x1, 0x1)
	/root/go/src/blichmann.eu/code/btrfscue/recon.go:120 +0x75e
blichmann.eu/code/btrfscue/subcommand.(*CommandSet).Run(0xc420052050, 0xc42000e140, 0x1, 0x1)
	/root/go/src/blichmann.eu/code/btrfscue/subcommand/subcommand.go:147 +0x52
blichmann.eu/code/btrfscue/subcommand.Run()
	/root/go/src/blichmann.eu/code/btrfscue/subcommand/subcommand.go:173 +0x48
main.main()
	/root/go/src/blichmann.eu/code/btrfscue/btrfscue.go:122 +0x18c

I'm not sure why this happens...
I will try to make the slice functionality (Data extraction) safer, but I don't think it's the cause of the real issue here?

LMK if there is more data I can provide.
Thanks :)

[cblichmann]

Hi @5ay3h,
Thanks for the report. It has been a while since I touched the project (lack of time, sadly). I will take a look at this, haven't seen this so far (maybe tomorrow evening CEST).
Cheers, Christian

[L3P3]

A shame the very same error still appears with the latest version.
I have no idea if that tool would have helped me recovering a few files anyway. If I knew it will, I would pay for it...

[cblichmann]

Yeah, I didn't have any spare time to work on this yet. I advice you to keep an image of the drive on file (no pun intended), so you can try with a future version.
Don't worry about paying anyone, this tool is supposed to remain free :)

[hartmark]

+1 have same problem

[cblichmann]

Care to try again? The latest commits should (fingers crossed) fix one such issue.

[hartmark]

Good job! Sadly I have already begun full wipe off the affected discs before sending them to a friend. I'll keep in mind to try the unfixed version of I need to try recover in the future to see if it's fixed.

[5ay3h]

Will try in 30 days from now 😅 Very exited

…

On Wed, Dec 19, 2018, 18:59 Markus Hartung ***@***.***> wrote: Good job! Sadly I have already begun full wipe off the affected discs before sending them to a friend. I'll keep in mind to try the unfixed version of I need to try recover in the future to see if it's fixed. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJfkqKFZT7oJgQSdFTeHELDuYgxLrkggks5u6tLdgaJpZM4U9TpG> .

[cblichmann]

Ok, pinging again later. If you try it out, you can use the mount to mount a read-only view of your damaged filesystem using FUSE.
That makes it convenient to assess the potential for data recovery.

[hartmark]

I tried cloning the repo again as I had cleaned it up. But now when I do make I get output that it have built a binary, but none is to be found. [Code] markus@staropramen ~/btrfscue (git)-[master] % make [Build] /home/markus/btrfscue/bin/btrfscue markus@staropramen ~/btrfscue (git)-[master] % ls bin ls: cannot access 'bin': No such file or directory 2 markus@staropramen ~/btrfscue (git)-[master] % mkdir bin :( markus@staropramen ~/btrfscue (git)-[master] % make [Build] /home/markus/btrfscue/bin/btrfscue markus@staropramen ~/btrfscue (git)-[master] % ls bin [/Code]

…

On 4 January 2019 13:29:07 CET, Christian Blichmann ***@***.***> wrote: Ok, pinging again later. If you try it out, you can use the `mount` to mount a read-only view of your damaged filesystem using FUSE. That makes it convenient to assess the potential for data recovery. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #2 (comment)

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[cblichmann]

Hmm, that's odd, I just tried this and it worked:

$ git clone --recurse-submodules https://github.com/cblichmann/btrfscue.git .
$ make
  [Build]     /home/cblichmann/devel/btrfscue/bin/btrfscue

[hartmark]

strange, I removed and started over one more time and now it compiles perfectly again. I'll try again now with the recon and see if it works better now with my second failed btrfs disk set :/

[hartmark]

I just tried it out and it seems to fail with same error:

1 markus@staropramen ~/btrfscue/bin (git)-[master] % sudo ./btrfscue identify /dev/sda
[sudo] password for markus:
 5455 / 97675 [==>--------------------------------------------------]   5.58% 11 63 6939 / 97675 [===>------------------------------------------------]   7.10%
 97675 / 97675 [================================================] 100.00% 12m34s
fsid                                 count entropy  block size                 
1fbb3b74-20d8-4c5c-9302-db5e6dfbd21b 45    4.000000 16384                      
a13d8d31-f12f-448f-b63c-9d44c29d1042 17    3.750000 16384                      
01000000-0200-0000-0100-000002000000 7     1.061278 0                          
sudo ./btrfscue identify /dev/sda  1.91s user 7.86s system 1% cpu 12:39.66 total

1 markus@staropramen ~/btrfscue/bin (git)-[master] % sudo ./btrfscue recon --id
1fbb3b74-20d8-4c5c-9302-db5e6dfbd21b --metadata metadata_sda.db /dev/sda       
 2.00 GB / 3.64 TB [>----------------------------------------------]   0.05% 11s
panic: runtime error: slice bounds out of range                                

goroutine 1 [running]:
blichmann.eu/code/btrfscue/btrfs.Leaf.Data(0xc0000c4000, 0x1000, 0x1000, 0x0, 0xfffffffffffffff6, 0x80114080, 0x70890a6000)                                    
        /home/markus/btrfscue/src/blichmann.eu/code/btrfscue/btrfs/leaf.go:129 +0xf6
main.(*reconCommand).Run(0xc0000b0020, 0xc00008a060, 0x1, 0x1)                 
        /home/markus/btrfscue/src/blichmann.eu/code/btrfscue/recon.go:120 +0x598
blichmann.eu/code/btrfscue/subcommand.(*CommandSet).Run(0xc000094000, 0xc00008a060, 0x1, 0x1)
        /home/markus/btrfscue/src/blichmann.eu/code/btrfscue/subcommand/subcommand.go:147 +0x52
blichmann.eu/code/btrfscue/subcommand.Run()                                    
        /home/markus/btrfscue/src/blichmann.eu/code/btrfscue/subcommand/subcommand.go:173 +0x48
main.main()
        /home/markus/btrfscue/src/blichmann.eu/code/btrfscue/btrfscue.go:123 +0x174

[cblichmann]

After playing around with newer BTRFS images, I have a test case that reproduces this now.

[hartmark]

Cool! Just poke me if I could test anything. I'm waiting for me replacement disk. It seems the vanilla rescue command lets me restore most data but it's good to have this too. How big files can I expect to be able to restore on a standard btrfs volume?

…

On 7 January 2019 09:31:17 CET, Christian Blichmann ***@***.***> wrote: After playing around with newer BTRFS images, I have a test case that reproduces this now. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #2 (comment)

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[cblichmann]

I haven't gotten around to actually implement the extend mapping (see issue #4), so for your block size (16KiB), you can restore files of up to ~15KiB in size. I know that this is not too useful yet, but I do have some experimental code lying around that deals with the full file extent data and have already used it to restore a few files I cared about from another "hopeless" image :) -- If #4 is done, you'll be able to restore files of any size.
The cool thing about the metadata index this tool uses, is that it should also be able to "undelete" files from a live disk. In limited cases, it's even possible to go back in time and view the whole disk at an earlier stage.

[hartmark]

Alright, I have backups on my most important data but there are some Plex server settings files I want to find so I don't have to redo my setup.

Do you have a branch with the test code for #4 ? Restoring bigger files are indeed an interesting feature. Have you poked the btrfs mailing list for any assistance on getting it running?

Perhaps the official recover program can be called with some parameters to avoid duplication of effort.

Being able to undelete files can Indeed be a really cool feature.

I have a raid1 with three discs, 4GiB, 3GiB, and 1GiB respectively. It would be neat to be able to use metadata from all discs if one copy is defective.

[5ay3h]

@cblichmann

It works !
(Sorry for the long delay.)

GJ mate 👍

now if we will just be able to recover all the files (with metadata), we could finally open the champagnes 😄