#6 error-NR 2133571363 inode or journal directory data error

[fsk141]

I've been working with ext4magic for the past 24 hours, and have gotten close to recovering my data, but feel there's a bug somewhere & would love help tracking it down.

https://sourceforge.net/p/ext4magic/tickets/3/#8f62 << I used the 'workaround.patch,' from your previous post, and it seemed to fix a myriad of issues, but I'm still unable to get anything other than a directory listing of my 'Documents' folder

I've tried many things, -m, -M, -r, -R, explicit file name's / folder name's, inode declarations, etc.

Brief backstory, have a 1tb ssd, accidentally did rm -rf, had trim enabled, happened in a split second. I shut the computer down asap (wish I would have made a journal backup, but wasn't thinking)

I'm currently running into error-NR 2133571363, and aren't quite sure what to trace. I'd be happy to provide any logs, and try anything.

I'm running the newest version of ext4magic, on a freshly updated arch linux system,

Linux 4.7.2-2-ck #1 SMP PREEMPT Fri Sep 2 21:17:53 PDT 2016 x86_64 GNU/Linux

$ ext4magic -V
ext4magic version : 0.3.2
libext2fs version : 1.43.3
CPU is little endian.

core/glibc 2.24-2 (base) [installed]

Any help would be much appreciated.

Thanks!

[fsk141]

For example, one of the output's for an inode search of my Documents folder returns the following:

$ sudo ext4magic /dev/mapper/home -a 1477970000 -R -I 3539014 -d /mnt/one

I get warnings like the following:
Warning: error-NR 2133571363 can not found file: <3539014>/WriteInMe/Write/words

and all of the files it does recover has a bunch of gook and random stuff inside (improperly recovering)

[fsk141]

A bit more information:

$ sudo ext4magic -S /dev/mapper/home
Filesystem in use: /dev/mapper/home

Filesystem volume name:
Last mounted on: /home
Filesystem UUID: c5a6cca1-6400-4b9f-bbd7-4181bac159d2
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 57491456
Block count: 229964800
Reserved block count: 11498240
Free blocks: 203087307
Free inodes: 57446412
First block: 0
Block size: 4096
Fragment size: 4096
Group descriptor size: 64
Reserved GDT blocks: 1024
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Wed Aug 31 21:45:45 2016
Last mount time: Mon Oct 31 23:28:59 2016
Last write time: Mon Oct 31 23:30:32 2016
Mount count: 55
Maximum mount count: -1
Last checked: Wed Aug 31 21:45:45 2016
Check interval: 0 ()
Lifetime writes: 731 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 32
Desired extra isize: 32
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 60915824-48b2-41b1-bbc8-9e077e25fb42
Journal backup: inode blocks
ext4magic : EXIT_SUCCESS

[Robi]

Hello fsk141,

You become the error-NR 2133571363 "EXT2_ET_DIR_CORRUPTED"
According to your error description, this can not work.
You're using SSD. Ext4magic is of course not suitable for the TRIM function. But you noticed the error early and protected the file system. Probably the data are not yet cleaned up and ext4magic would have a chance. But ext4magic see there a other problem.

Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize

The Filesystem is a real 64bit filesystem, this is not implemented and
See also:
http://lists.opensuse.org/opensuse-factory/2012-03/msg00562.html

robi6

[fsk141]

Is there anything I can do, I have an image, and noticed that the data is
there, I just aren't sure how to either recreate or restore the nodes. Any
other software or advice you can recommend?

On Nov 3, 2016 11:43 AM, "Robi" robi6@users.sf.net wrote:

Hello fsk141,

You become the error-NR 2133571363 "EXT2_ET_DIR_CORRUPTED"
According to your error description, this can not work.
You're using SSD. Ext4magic is of course not suitable for the TRIM
function. But you noticed the error early and protected the file system.
Probably the data are not yet cleaned up and ext4magic would have a chance.
But ext4magic see there a other problem.

Filesystem features: has_journal ext_attr resize_inode dir_index filetype
extent 64bit flex_bg sparse_super large_file huge_file dir_nlink
extra_isize

The Filesystem is a real 64bit filesystem, this is not implemented and
See also:
http://lists.opensuse.org/opensuse-factory/2012-03/msg00562.html

robi6

• [tickets:#6] https://sourceforge.net/p/ext4magic/tickets/6/ error-NR
  2133571363 <2133571363> inode or journal directory data error*

Status: open
Created: Thu Nov 03, 2016 04:02 AM UTC by fsk141
Last Updated: Thu Nov 03, 2016 04:11 AM UTC
Owner: nobody

I've been working with ext4magic for the past 24 hours, and have gotten
close to recovering my data, but feel there's a bug somewhere & would love
help tracking it down.

https://sourceforge.net/p/ext4magic/tickets/3/#8f62 << I used the
'workaround.patch,' from your previous post, and it seemed to fix a myriad
of issues, but I'm still unable to get anything other than a directory
listing of my 'Documents' folder

I've tried many things, -m, -M, -r, -R, explicit file name's / folder
name's, inode declarations, etc.

Brief backstory, have a 1tb ssd, accidentally did rm -rf, had trim
enabled, happened in a split second. I shut the computer down asap (wish I
would have made a journal backup, but wasn't thinking)

I'm currently running into error-NR 2133571363, and aren't quite sure
what to trace. I'd be happy to provide any logs, and try anything.

I'm running the newest version of ext4magic, on a freshly updated arch
linux system,

Linux 4.7.2-2-ck #1 SMP PREEMPT Fri Sep 2 21:17:53 PDT 2016 x86_64
GNU/Linux

$ ext4magic -V
ext4magic version : 0.3.2
libext2fs version : 1.43.3
CPU is little endian.

core/glibc 2.24-2 (base) [installed]

Any help would be much appreciated.

Thanks!

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/ext4magic/tickets/6/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[Robi]

The extundelte and ext4magic tools were created at the time of e2fsprogs-1.41.9.
In the meantime, some new features have been added, which are not included there. For example, 64bit ext4 file systems. Such 64bit file systems can not work with these tools. This is already noticeable a long time ago. https://sourceforge.net/p/extundelete/mailman/message/29988846/

This option is only required on ext4 volumes 16 TiB and larger.
In most distributions and a long time, this option was automatically set only for such very large file systems. (But, some manufacturers or distributors have always used by default 64bit for all ext4)
In versions of e2fsprogs 1.43 mke2fs will now create file systems with 64bit features enabled by default.
This also makes problems with other programs and tools, for example, some bootloaders. In some cases, it is again set to auto_64-bit_support within the distributions.

In summary, I do not know currently an opensource tool which can recover deleted files from old journal data, if in the ext4 file system the 64bit flag is set.

I'm sorry