Hi everybody!
I recently damaged an ext4 partition by accident (mistakenly forced
a RAID sync with another partition onto it, which I realized after
about 3% completion). As a result the beginning of the ext4 partition
seems to be overwritten with garbage and refuses to mount.
As you might guess, I'd now like to get as most of my data back (from
the part which hasn't been overwritten, of course :)).
Maybe somebody knows a good method to just "repair" the ext4-structure
from the remaining part of the partition?
Background information:
Operation system:?? Debian GNU/Linux 6.0.4 (Squeeze)
Kernel:???????????? Linux 2.6.32-5
Architecture:?????? x86-amd64
e2fsprogs:????????? 1.41.12
Filesystem type:??? ext4, with default settings (mkfs.ext4 /dev/xyz)
Filesystem size:??? Around 1TB, filled with around 800GB of data.
Filesystem content: From a lot of ASCII stuff up to files with several
??????????????????? GB in size and arbitrary non-standard type.
What I've tried so far:
* First of all, though the source drive is physically fine, I work on
? images of the partition on a spare drive, to experiment with. Everytime
? I make unrecoverable errors to that image, I recopy the original.
* "dumpe2fs -b $SBERR /dev/loop0" does NOT work, for SBERR={32768, 98304,
? 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000,
? 7962624} ( see https://pzt.me/1l55 )
* "dumpe2fs -b $SBOK /dev/loop0" DOES (partly) work, for SBOK={11239424,
? 20480000, 23887872, 71663616, 78675968, 214990848} ( see https://pzt.me/6txz )
* "mkfs.ext4 -S /dev/loop0" results in a completely empty filesystem
* "fsck.ext4 -b $SBOK -B 4096 -v -n /dev/loop0" shows a lot of errors.
? Filesystem isn't mountable afterwards ( see https://pzt.me/42yk and
? https://pzt.me/3frg )
* "fsck.ext4 -b $SBOK -B 4096 -v -y /dev/loop0" recoveres after a long time.
? Filesystem is mountable. Root is empty besides lost+found folder, which
? contains about 300GB mostly useless data: Millions of files with wrong
? permissions, useless names and some random content.
* photorec from the testdisk package recoveres, luckily!, about 500GB of
? data. Though the content seems to be pretty reasonable, no filenames
? are recovered, since photorec operates without using filesystem knowledge.
Do you see any chances (besides consulting professional recovery companies)
getting the filenames back? I looked into the ext4 specs a bit to figure out
where this information is stored on disk, but before I step with hexedit
through a terabyte of data, I'd rather try some solutions which are maybe
already out there.
Any help is appretiated.
Thanks in advance, Rudolf.
On 2012-02-09, at 9:29 AM, Rudolf Zran wrote:
> I recently damaged an ext4 partition by accident (mistakenly forced
> a RAID sync with another partition onto it, which I realized after
> about 3% completion). As a result the beginning of the ext4 partition
> seems to be overwritten with garbage and refuses to mount.
>
> As you might guess, I'd now like to get as most of my data back (from
> the part which hasn't been overwritten, of course :)).
>
> Maybe somebody knows a good method to just "repair" the ext4-structure
> from the remaining part of the partition?
>
>
> Background information:
>
> Operation system: Debian GNU/Linux 6.0.4 (Squeeze)
> Kernel: Linux 2.6.32-5
> Architecture: x86-amd64
> e2fsprogs: 1.41.12
> Filesystem type: ext4, with default settings (mkfs.ext4 /dev/xyz)
> Filesystem size: Around 1TB, filled with around 800GB of data.
> Filesystem content: From a lot of ASCII stuff up to files with several
> GB in size and arbitrary non-standard type.
>
>
> What I've tried so far:
>
> * First of all, though the source drive is physically fine, I work on
> images of the partition on a spare drive, to experiment with. Everytime
> I make unrecoverable errors to that image, I recopy the original.
>
> * "dumpe2fs -b $SBERR /dev/loop0" does NOT work, for SBERR={32768, 98304,
> 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000,
> 7962624} ( see https://pzt.me/1l55 )
>
> * "dumpe2fs -b $SBOK /dev/loop0" DOES (partly) work, for SBOK={11239424,
> 20480000, 23887872, 71663616, 78675968, 214990848} ( see https://pzt.me/6txz )
>
> * "mkfs.ext4 -S /dev/loop0" results in a completely empty filesystem
>
> * "fsck.ext4 -b $SBOK -B 4096 -v -n /dev/loop0" shows a lot of errors.
> Filesystem isn't mountable afterwards ( see https://pzt.me/42yk and
> https://pzt.me/3frg )
>
> * "fsck.ext4 -b $SBOK -B 4096 -v -y /dev/loop0" recoveres after a long time.
> Filesystem is mountable. Root is empty besides lost+found folder, which
> contains about 300GB mostly useless data: Millions of files with wrong
> permissions, useless names and some random content.
The ability to recover from something like this depends heavily on where
the directory structure and inodes were located. Filesystems tend to use
the start of the disk first, because it has the best performance (about 2x
as fast as the end).
> * photorec from the testdisk package recoveres, luckily!, about 500GB of
> data. Though the content seems to be pretty reasonable, no filenames
> are recovered, since photorec operates without using filesystem knowledge.
>
> Do you see any chances (besides consulting professional recovery companies)
> getting the filenames back?
There was an ext3grep tool that some people had success with, but when I
looked at it, it was still fairly complex to use.
> I looked into the ext4 specs a bit to figure out
> where this information is stored on disk, but before I step with hexedit
> through a terabyte of data, I'd rather try some solutions which are maybe
> already out there.
>
> Any help is appretiated.
>
> Thanks in advance, Rudolf.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Cheers, Andreas
Hello Andreas!
[ext4 partition overwritten with garbage at the beginning]
>> * photorec from the testdisk package recoveres, luckily!, about 500GB of
>> ? data. Though the content seems to be pretty reasonable, no filenames
>> ? are recovered, since photorec operates without using filesystem
>> ? knowledge.
>>
>> Do you see any chances (besides consulting professional recovery companies)
>> getting the filenames back?
>
> There was an ext3grep tool that some people had success with, but when I
> looked at it, it was still fairly complex to use.
Thanks for the hint, but the problem with ext3grep is that it seems to
rely on an intact filesystem structure. It even has no option to set
another superblock besides the default one and fails with all commands
I tried ( see https://pzt.me/8q6k ).
Bye, Rudolf.
On Thu, 09 Feb 2012 16:29:53 +0000, Rudolf Zran wrote:
> Hi everybody!
>
> I recently damaged an ext4 partition by accident (mistakenly forced a
> RAID sync with another partition onto it, which I realized after about
> 3% completion). As a result the beginning of the ext4 partition seems to
> be overwritten with garbage and refuses to mount.
>
> As you might guess, I'd now like to get as most of my data back (from
> the part which hasn't been overwritten, of course :)).
>
> Maybe somebody knows a good method to just "repair" the ext4-structure
> from the remaining part of the partition?
>
>
> Background information:
>
> Operation system: Debian GNU/Linux 6.0.4 (Squeeze) Kernel:
> Linux 2.6.32-5 Architecture: x86-amd64 e2fsprogs: 1.41.12
> Filesystem type: ext4, with default settings (mkfs.ext4 /dev/xyz)
> Filesystem size: Around 1TB, filled with around 800GB of data.
> Filesystem content: From a lot of ASCII stuff up to files with several
> GB in size and arbitrary
> non-standard type.
>
>
> What I've tried so far:
>
> * First of all, though the source drive is physically fine, I work on
> images of the partition on a spare drive, to experiment with.
> Everytime I make unrecoverable errors to that image, I recopy the
> original.
>
> * "dumpe2fs -b $SBERR /dev/loop0" does NOT work, for SBERR={32768,
> 98304,
> 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000,
> 7962624} ( see https://pzt.me/1l55 )
>
> * "dumpe2fs -b $SBOK /dev/loop0" DOES (partly) work, for SBOK={11239424,
> 20480000, 23887872, 71663616, 78675968, 214990848} ( see
> https://pzt.me/6txz )
>
> * "mkfs.ext4 -S /dev/loop0" results in a completely empty filesystem
>
> * "fsck.ext4 -b $SBOK -B 4096 -v -n /dev/loop0" shows a lot of errors.
> Filesystem isn't mountable afterwards ( see https://pzt.me/42yk and
> https://pzt.me/3frg )
>
> * "fsck.ext4 -b $SBOK -B 4096 -v -y /dev/loop0" recoveres after a long
> time.
> Filesystem is mountable. Root is empty besides lost+found folder,
> which contains about 300GB mostly useless data: Millions of files
> with wrong permissions, useless names and some random content.
>
> * photorec from the testdisk package recoveres, luckily!, about 500GB of
> data. Though the content seems to be pretty reasonable, no filenames
> are recovered, since photorec operates without using filesystem
> knowledge.
>
> Do you see any chances (besides consulting professional recovery
> companies) getting the filenames back? I looked into the ext4 specs a
> bit to figure out where this information is stored on disk, but before I
> step with hexedit through a terabyte of data, I'd rather try some
> solutions which are maybe already out there.
The best, simplest and safest plan I think, would be simply to format the
partition and restore from backup.
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive: http://lists.debian.org/[email protected]
On 02/09/2012 10:22 PM, Rudolf Zran wrote:
> Hello Andreas!
>
>
> [ext4 partition overwritten with garbage at the beginning]
>
>
>>> * photorec from the testdisk package recoveres, luckily!, about 500GB of
>>> data. Though the content seems to be pretty reasonable, no filenames
>>> are recovered, since photorec operates without using filesystem
>>> knowledge.
>>>
>>> Do you see any chances (besides consulting professional recovery companies)
>>> getting the filenames back?
>>
>> There was an ext3grep tool that some people had success with, but when I
>> looked at it, it was still fairly complex to use.
>
> Thanks for the hint, but the problem with ext3grep is that it seems to
> rely on an intact filesystem structure. It even has no option to set
> another superblock besides the default one and fails with all commands
> I tried ( see https://pzt.me/8q6k ).
>
I have written some tools in the past to recover the file structure of
an over-formated ext3/ext4 device based on directory blocks.
With some tweaks it should be able to assign the file#inode_numbers in
lost+found to a directory structure.
Problem is that I'm rather busy with too many other projects already. Do
you know C and could you add some code on your own for the lost+found
assignment? I can assist you, but it is unlikely that I find much time
do it myself...
Cheers,
Bernd
Hello Bernd!
> I have written some tools in the past to recover the file structure of
> an over-formated ext3/ext4 device based on directory blocks.
> With some tweaks it should be able to assign the file#inode_numbers in
> lost+found to a directory structure.
> Problem is that I'm rather busy with too many other projects already. Do
> you know C and could you add some code on your own for the lost+found
> assignment? I can assist you, but it is unlikely that I find much time
> do it myself...
I'm not that fluent in C, but I could just give it a try. Since it's my
own data and this recovery for personal "fun" I can't do something bad
with it :) So, if you could share the code I'd be happy!
Thanks, Rudolf.
On Feb 9, 2012, at 11:29 AM, Rudolf Zran wrote:
> Hi everybody!
>
> I recently damaged an ext4 partition by accident (mistakenly forced
> a RAID sync with another partition onto it, which I realized after
> about 3% completion). As a result the beginning of the ext4 partition
> seems to be overwritten with garbage and refuses to mount.
>
> As you might guess, I'd now like to get as most of my data back (from
> the part which hasn't been overwritten, of course :)).
>
> Maybe somebody knows a good method to just "repair" the ext4-structure
> from the remaining part of the partition?\
Have you tried just simply running e2fsck, specifying an alternate superblock?
I'd do this by making a copy of the file system first, of course?.
-- Ted
Hello Ted!
>> I recently damaged an ext4 partition by accident
[...]
>> Maybe somebody knows a good method to just "repair" the
>> ext4-structure from the remaining part of the partition?
>
> Have you tried just simply running e2fsck, specifying an alternate superblock?
Yes of course I tried, as I wrote in my original post ($SBOK is one
of the intact superblocks at 11239424, 20480000, 23887872, 71663616,
78675968 and 214990848).
With "all answers: no":
>> * "fsck.ext4 -b $SBOK -B 4096 -v -n /dev/loop0" shows a lot of errors.
>> Filesystem isn't mountable afterwards
# fsck.ext4 -b 214990848 -B 4096 -v -n /dev/loop0
e2fsck 1.41.12 (17-May-2010)
One or more block group descriptor checksums are invalid. Fix? no
Group descriptor 0 checksum is invalid. IGNORED.
Group descriptor 1 checksum is invalid. IGNORED.
...
Group descriptor 7451 checksum is invalid. IGNORED.
Group descriptor 7452 checksum is invalid. IGNORED.
/dev/loop0 contains a file system with errors, check forced.
Resize inode not valid. Recreate? no
Pass 1: Checking inodes, blocks, and sizes
Root inode is not a directory. Clear? no
Inode 5 should not have EOFBLOCKS_FL set (size 2642074971391648798, lblk -1)
Clear? no
...
# mount -o ro /dev/loop0 /mnt
mount: /dev/loop0: can't read superblock
# dmesg
[504508.215515] EXT4-fs error (device loop0): ext4_iget: bad extended attribute block 1920620055 in inode #2
[504508.215530] EXT4-fs (loop0): get root inode failed
[504508.215534] EXT4-fs (loop0): mount failed
With "all answers: yes":
>> * "fsck.ext4 -b $SBOK -B 4096 -v -y /dev/loop0" recoveres after a long time.
>> Filesystem is mountable. Root is empty besides lost+found folder, which
>> contains about 300GB mostly useless data: Millions of files with wrong
>> permissions, useless names and some random content.
> I'd do this by making a copy of the file system first, of course….
For sure! :) I solely work on copies.
Thanks, Rudolf.
On Fri, Feb 10, 2012 at 06:36:52PM +0000, Rudolf Zran wrote:
> >> * "fsck.ext4 -b $SBOK -B 4096 -v -y /dev/loop0" recoveres after a long time.
> >> Filesystem is mountable. Root is empty besides lost+found folder, which
> >> contains about 300GB mostly useless data: Millions of files with wrong
> >> permissions, useless names and some random content.
>
> > I'd do this by making a copy of the file system first, of course….
I would have expected at least some subdirectories from your directory
hierarcy that contained useful content.
Just to set expectations, things that you might do that tried to look
for directory blocks, etc., *might* give you more useful filenames as
opposed to random inode numbers in lost+found, but it's unlikely to
recover any more *files*. It sounds most of your files were located
in part of the inode table that got smashed, and so short of looking
at each data block to find useful bits, I doubt spending a lot of time
on trying to use or create more recovery tools based on file system
metadata is likely to result in more data getting recovered.
- Ted
P.S. e2fsck -n by definition opens the block device read-only, so
it's not at all surprising you couldn't mount it after e2fsck -n; it
wouldn't have changed anything.
On 02/10/2012 10:32 PM, Ted Ts'o wrote:
> On Fri, Feb 10, 2012 at 06:36:52PM +0000, Rudolf Zran wrote:
>>>> * "fsck.ext4 -b $SBOK -B 4096 -v -y /dev/loop0" recoveres after a long time.
>>>> Filesystem is mountable. Root is empty besides lost+found folder, which
>>>> contains about 300GB mostly useless data: Millions of files with wrong
>>>> permissions, useless names and some random content.
>>
>>> I'd do this by making a copy of the file system first, of course….
>
> I would have expected at least some subdirectories from your directory
> hierarcy that contained useful content.
>
> Just to set expectations, things that you might do that tried to look
> for directory blocks, etc., *might* give you more useful filenames as
> opposed to random inode numbers in lost+found, but it's unlikely to
> recover any more *files*. It sounds most of your files were located
> in part of the inode table that got smashed, and so short of looking
> at each data block to find useful bits, I doubt spending a lot of time
> on trying to use or create more recovery tools based on file system
> metadata is likely to result in more data getting recovered.
>
You do not need inode tables to get back a basic directory structure.
Assigning directory blocks with '.' and '..' and then with real content
provide the file system structure and also inode-number to name
translation. Even better would be if secondary blocks also would have
'.' and '..'.
Cheers,
Bernd
On 02/10/2012 06:07 PM, Rudolf Zran wrote:
> Hello Bernd!
>
>
>> I have written some tools in the past to recover the file structure of
>> an over-formated ext3/ext4 device based on directory blocks.
>> With some tweaks it should be able to assign the file#inode_numbers in
>> lost+found to a directory structure.
>> Problem is that I'm rather busy with too many other projects already. Do
>> you know C and could you add some code on your own for the lost+found
>> assignment? I can assist you, but it is unlikely that I find much time
>> do it myself...
>
> I'm not that fluent in C, but I could just give it a try. Since it's my
> own data and this recovery for personal "fun" I can't do something bad
> with it :) So, if you could share the code I'd be happy!
I'm going upload the existing code on Sunday. Going to travel tomorrow
and I need to go to bed now.
Sorry for the day!
Cheers,
Bernd
Hi List!
In an offlist reply someone recommended me ext4magic (see
http://developer.berlios.de/projects/ext4magic ).
Like magic it recovered complete directory hierarchies with filenames,
timestamps, even ownership and permissions for more than 300GB of the
deleted data.
I can recommend this to everybody who accidently destroyed parts of
his filesystem. In contrast to fsck ext4magic doesn't try to repair,
but just extracts the data completely in read only mode (feelslike
"tar xf" actually :).It's easier to use and understand and way more
effective when it comesto recovery. ext4magic shouldn't be missing
in any good recovery collection.
Thanks to all helping me out in this case.
Have a nice weekend, Rudolf.
On Sat, Feb 11, 2012 at 05:33:30PM +0000, Rudolf Zran wrote:
> Hi List!
>
> In an offlist reply someone recommended me ext4magic (see
> http://developer.berlios.de/projects/ext4magic ).
I wasn't familiar with ext4magic, so thanks for recommending it.
After taking a quick look at its wiki page, it looks like worthy
successor to ext3grep (which only works on ext3 file systems). It
appears from their web page (I haven't had a chance to play with it
yet) that it uses a variety of techniques to recover data, which
combined should work really well.
Thanks for reporting back!
- Ted
On 2012-02-11, at 11:30 AM, Ted Ts'o wrote:
> On Sat, Feb 11, 2012 at 05:33:30PM +0000, Rudolf Zran wrote:
>> Hi List!
>>
>> In an offlist reply someone recommended me ext4magic (see
>> http://developer.berlios.de/projects/ext4magic ).
>
> I wasn't familiar with ext4magic, so thanks for recommending it.
> After taking a quick look at its wiki page, it looks like worthy
> successor to ext3grep (which only works on ext3 file systems). It
> appears from their web page (I haven't had a chance to play with it
> yet) that it uses a variety of techniques to recover data, which
> combined should work really well.
Looks interesting and useful... I wonder if it makes sense to include
this into e2fsprogs at some point, so that it is available when users
need it most...
Cheers, Andreas
On Sat, Feb 11, 2012 at 11:47:14AM -0700, Andreas Dilger wrote:
>
> Looks interesting and useful... I wonder if it makes sense to include
> this into e2fsprogs at some point, so that it is available when users
> need it most...
We'll need to talk to the author about that. At the very least it
would be good to translate the ext4magic wiki into English, so that
people who are doing web searches are more likely to find it. :-)
- Ted
Hi list !
I am the developer of ext4magic
On Sat, Feb 11, 2012 at 11:47:14AM -0700, Andreas Dilger wrote:
>> Looks interesting and useful... I wonder if it makes sense to include
>> this into e2fsprogs at some point, so that it is available when users
>> need it most...
Ted Ts'o wrote:
> We'll need to talk to the author about that. At the very least it
> would be good to translate the ext4magic wiki into English, so that
> people who are doing web searches are more likely to find it. :-)
I think inside of e2fsprogs is not the place for ext4magic.
A good optional extension, probably, but a standard tool, never.
There are destroyed, deleted or lost structures and there is a lot of
heuristic function. Installation on a production server is a no go for
any administrator.
Useable for some small forensic problems and a last chance to recover
some lost files. Nobody needs this regularly.
Everyone has a good backup, and no one destroy its files and file systems.
It is very rarely needed. The users prefer extundelete. This is buggy,
the development sleeps for 2 years, on the mailing list no answers,
but it is easy to use and there are many HOWTOs, and all love it ;-)
One of the problems of ext4magic, of course, no English documentation.
But at the moment is the one man show, and my English is a disaster.
The world would laugh at it. I need some help for translation.
Proofread, for a native speaker with technical understanding a few minutes work,
for me ...
We'll see, I try
Regards,
Roberto Maar
On Mon, Feb 13, 2012 at 11:00:21AM +0100, Maar, Roberto wrote:
> Everyone has a good backup, and no one destroy its files and file systems.
If only that were true. :-)
Of course the developers who can do a good job writing recovery
programs are smart enough to do regular backups. This is why tools
like extundelete and ext4magic generally don't get a lot of volunteers
to help with documentation and development.
But you'd be amazed how many people contact me, or the ext4 list, or
the ext3-users list, asking for help, and who obviously had _not_ been
doing regular backups. :-(
>
> One of the problems of ext4magic, of course, no English documentation.
> But at the moment is the one man show, and my English is a disaster.
> The world would laugh at it. I need some help for translation.
> Proofread, for a native speaker with technical understanding a few minutes work,
> for me ...
> We'll see, I try
Well, I can certainly call for help, and see if there are folks who
would be interested in helping you with the translation and
creating/improving the English documentation
And now that I know about it, I'll certainly be pointing people at it.
Thanks for creating it!
- Ted
On Mon, Feb 13, 2012 at 10:51 AM, Ted Ts'o <[email protected]> wrote:
> On Mon, Feb 13, 2012 at 11:00:21AM +0100, Maar, Roberto wrote:
>> Everyone has a good backup, and no one destroy its files and file systems.
>
> If only that were true. ?:-)
>
> Of course the developers who can do a good job writing recovery
> programs are smart enough to do regular backups. ?This is why tools
> like extundelete and ext4magic generally don't get a lot of volunteers
> to help with documentation and development.
>
> But you'd be amazed how many people contact me, or the ext4 list, or
> the ext3-users list, asking for help, and who obviously had _not_ been
> doing regular backups. ?:-(
>
>>
>> One of the problems of ext4magic, of course, no English documentation.
>> But at the moment is the one man show, and my English is a disaster.
>> The world would laugh at it. I need some help for translation.
>> Proofread, for a native speaker with technical understanding a few minutes work,
>> for me ...
>> We'll see, I try
>
> Well, I can certainly call for help, and see if there are folks who
> would be interested in helping you with the translation and
> creating/improving the English documentation
>
> And now that I know about it, I'll certainly be pointing people at it.
>
> Thanks for creating it!
>
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?- Ted
I took a minute and tried to put together a opensuse package for
ext4magic in my home directory for testing.
https://build.opensuse.org/package/show?package=ext4magic&project=home%3Agregfreemyer%3ATools-for-forensic-boot-cd
I haven't tried to patch the source, but at present it has some
compile errors that keep OBS from publishing it even from a home
directory.
====
I: Program returns random data in a function
E: ext4magic no-return-in-nonvoid-function hard_link_stack.c:87
E: ext4magic no-return-in-nonvoid-function imap_search.c:362
E: ext4magic no-return-in-nonvoid-function magic_block_scan.c:203, 1028, 249
I: A function uses a 'return;' statement, but has actually a value
to return, like an integer ('return 42;') or similar.
W: ext4magic voidreturn ext4magic.c:888
I: Program is using implicit definitions of functions getting
pointers or implemented by macros. These functions need to use their
correct prototypes to allow correct argument passing on e.g. x86_64 .
- Implicit memory/string functions need #include <string.h>.
- Implicit *printf functions need #include <stdio.h>.
- Implicit *printf functions need #include <stdio.h>.
- Implicit *read* functions need #include <unistd.h>.
- Implicit *recv* functions need #include <sys/socket.h>.
W: ext4magic implicit-pointer-decl journal.c:754
=====
I think just the E: errors are mandatory to fix for OBS to publish the
package, but I'm not sure about that.
Roberto, if you think you'll come out with a cleaner build in the next
couple weeks, I won't bother to patch up those errors.
Thanks
Greg
On Mon, Feb 13, 2012 at 11:00:21AM +0100, Maar, Roberto wrote:
> Everyone has a good backup, and no one destroy its files and file systems.
I think this is less true than you think.
Even if this is a rarely needed tool, having it as part of e2fsprogs with a good man page means that the users who need it will be able to find it more easily.
> One of the problems of ext4magic, of course, no English documentation.
> But at the moment is the one man show, and my English is a disaster.
> The world would laugh at it. I need some help for translation.
I think that your English is likely better than my German. I'm also always disappointed (but no longer surprised) by the poor quality of writing that native English speakers produce, so I don't think you have anything to worry about.
Possibly the easiest way to start is to use Google translate to convert the German wiki into English, post it to your site, and then ask for help in fixing it up.
> Proofread, for a native speaker with technical understanding a few minutes work, for me ...
Exactly. Since you already have a wiki in German, automated translation will hopefully get it to the point where some English writer can fix it up.
Cheers, Andreas
On Tuesday, February 14, 2012 1:25 AM, Greg Freemyer wrote:
> I took a minute and tried to put together a opensuse package for
> ext4magic in my home directory for testing.
> I haven't tried to patch the source, but at present it has some
> compile errors that keep OBS from publishing it even from a home
> directory.
> Roberto, if you think you'll come out with a cleaner build in the next
> couple weeks, I won't bother to patch up those errors.
Ops, a little dirty code. Full compiler checking, I've never tried. ;-(
Let me clean up this and one more intensive checking for all sorts of memory problems.
Think then ext4magic is ready to prove whether it is usable and useful.
The proposal to try a translation direct on the wiki is a good idea.
Thank you all for your interest for ext4magic, this gives me new energy
and positive motivation to work on it.
Regards,
Roberto Maar