Recovering files from ext2/3

jd1008 jd1008 at gmail.com
Sun Sep 21 01:30:01 UTC 2014


On 09/20/2014 07:15 PM, Robert Nichols wrote:
> On 09/19/2014 08:16 PM, Chris Murphy wrote:
>>
>> On Sep 19, 2014, at 11:49 AM, jd1008 <jd1008 at gmail.com> wrote:
>>
>>>
>>> On 09/19/2014 08:39 AM, Robert Nichols wrote:
>>>> On 09/18/2014 10:57 PM, jd1008 wrote:
>>>>> I ran mkfs.ext3 -S  /dev/sdc7
>>>>> then ran fsck.ext3 -y /dev/sdc7
>>>>> it blew away EVERYTHING :)
>>>>>
>>>>> Back to square one and re-dd original to test drive
>>>>> and start over.
>>>>
>>>> Ouch!  That _used_ to work.  Trying it just now, "mke3fs -S" seems
>>>> to clear a substantial portion of the inodes, which the manpage
>>>> specifically says it should _not_ do, and then /fsck/ completes the
>>>> destruction by moving all of the remaining inodes to lost+found.
>>>>
>>>> Sorry about that.
>>>>
>>> Can raise a bug against it?
>>
>> Chances are this is an upstream bug, or a misunderstanding. You 
>> should post your reproduce steps to the ext4 list, what you expect to 
>> happen based on man page, and what actually happens.
>> http://vger.kernel.org/vger-lists.html#linux-ext4
>
> It might be better for someone besides me to do that.  I'm running an
> RHEL 6 clone, which uses e2fsprogs-1.41.12.  If I post on the mailing
> list I'll immediately be told to upgrade to the latest version. Since
> my ox is not the one being gored here, I'm reluctant to jump through
> the hoops needed to do that.
>
/ posted it to the ext3 maling list (turns out they also know ext4)
and they admitted about undocumented effects of using the -S
option, and that one must NEVER use it unless they know the intrinsics
of the FS so well, that the user knows exactly what effects it will
have.

/


More information about the users mailing list