Is there any way to revert the stupid mistyping of "rm file *" on ext3??
I hope there is a way, because I dont have a backup of some files i
mistakenly deleted
Any help appreciated!
Thanks
Max
--
Max Valdez <[email protected]>
> Is there any way to revert the stupid mistyping of "rm file *" on ext3??
There is no simple way, no.
> I hope there is a way, because I dont have a backup of some files i
> mistakenly deleted
The only thing I can suggest is this:
* Do not write anything else to the partition, and immediately
re-mount it read-only.
E.G.:
mount -oremount -oro /dev/hda3
* Use dd to copy the entire contents of the partition to a file on
another partition.
E.G.:
dd if=/dev/hda3 of=/partition_image
* Search through that file for the fragments of your lost files.
E.G.:
grep "Some text that you are looking for" /partition_image
If it is a text file that you've lost, it's possible that you might be
able to recover some of it quite easily, using grep to search for the
fragments. If it's anything else, you'll probably not be able to
recover it, unless you have the details of the file format.
John.
On Jan 07, Max Valdez <[email protected]> wrote:
>Is there any way to revert the stupid mistyping of "rm file *" on ext3??
No.
>I hope there is a way, because I dont have a backup of some files i
>mistakenly deleted
Life sucks...
--
ciao,
Marco
Max Valdez wrote:
> Is there any way to revert the stupid mistyping of "rm file *" on ext3??
>
> I hope there is a way, because I dont have a backup of some files i
> mistakenly deleted
>
> Any help appreciated!
> Thanks
> Max
Try e2undel on sourceforge. You MIGHT be able to recover something. I
think. Good luck regardless.
-David
> There is no simple way, no.
What about IDE Taskfile access, it's help says something like it's the
crown jewel of hard drive forensics.
One question, how ext2/3 deletes files? similarily to fat by renaming the
first character?
Regards,
Maciej Soltysiak
On Tue, Jan 07, 2003 at 10:29:06AM +0100, Maciej Soltysiak wrote:
> > There is no simple way, no.
> What about IDE Taskfile access, it's help says something like it's the
> crown jewel of hard drive forensics.
>
> One question, how ext2/3 deletes files? similarily to fat by renaming the
> first character?
No. By removing the directory entry completely and marking the inode
unused.
By the way, there used to be undelete tool for ext2. It created a list
of deleted inodes with correct stat, but no names, only their inode
numbers. You could then pick the corect inode and give it a name, thus
bringing it back to life. Since ext3 is just ext2 with journal, I guess
it might work. It existed as a standalone tool and integrated to
midnight commander.
-------------------------------------------------------------------------------
Jan 'Bulb' Hudec <[email protected]>
I recall a tutorial explaining how to do that on ext2 with debugfs. Perhaps the same technique/tool can be used with ext3. Try to find it.
Alexandr Sandler
> I hope there is a way, because I dont have a backup of some files i
> mistakenly deleted
> > There is no simple way, no.
> What about IDE Taskfile access, it's help says something like it's the
> crown jewel of hard drive forensics.
What *is* IDE Taskfile access exactly?
I assumed it was a way of accessing a list of queued commands in the
device that had not been processed yet.
John.
On Tue, Jan 07, 2003 at 11:30:27AM +0000, John Bradford wrote:
> > > There is no simple way, no.
> > What about IDE Taskfile access, it's help says something like it's the
> > crown jewel of hard drive forensics.
>
> What *is* IDE Taskfile access exactly?
>
> I assumed it was a way of accessing a list of queued commands in the
> device that had not been processed yet.
An alternate low-levelish protocol to communicate
with IDE devices. In the present "Subject:" scope,
it is way below of what filesystems do.
The "ext2 undelete" tool might help, as filesystem
layout of EXT3 is identical to that of EXT2.
> John.
/Matti Aarnio
On Tue, 2003-01-07 at 11:30, John Bradford wrote:
> > > There is no simple way, no.
> > What about IDE Taskfile access, it's help says something like it's the
> > crown jewel of hard drive forensics.
>
> What *is* IDE Taskfile access exactly?
>
> I assumed it was a way of accessing a list of queued commands in the
> device that had not been processed yet.
Its a more formalised interface to issue commands to the controller.
Each IDE command has a series of phases you have to issue in the
right order. The taskfile ioctls ensure you can issue pretty much
any command safely
>
> By the way, there used to be undelete tool for ext2. It created a list
> of deleted inodes with correct stat, but no names, only their inode
> numbers. You could then pick the corect inode and give it a name, thus
> bringing it back to life. Since ext3 is just ext2 with journal, I guess
> it might work. It existed as a standalone tool and integrated to
> midnight commander.
>
I think there must be some other differences between ext2 and ext3, I've
tryed e2undel and unrm, both made for ext2, and none of them found any
deleted inode.
I umonted immediately the drive, and nothing has been writen on it after
the rm *
Thanks for the comments !
I will keep searching !
Max
--
uname -a: Linux garaged.fis.unam.mx 2.4.20-rc2-ac3 #2 SMP Thu Nov 21 17:15:31 UTC 2002 i686 unknown unknown GNU/Linux
-----BEGIN GEEK CODE BLOCK-----
GS/ d-s:a-C++ILIHA+++P-L++E--W++N+K-w++++O-M--V--PS+PEY+PGP-tXRtv++b+DI--D+Ge++h---r+++z+++
-----END GEEK CODE BLOCK-----
gpg-key: http://garaged.homeip.net/gpg-key.txt
On Jan 07, 2003 11:38 -0600, Max Valdez wrote:
> I think there must be some other differences between ext2 and ext3, I've
> tryed e2undel and unrm, both made for ext2, and none of them found any
> deleted inode.
Yes, in order to ensure that ext3 can safely resume an unlink after a
crash, it actually zeros out the block pointers in the inode, whereas
ext2 just marks these blocks as unused in the block bitmaps and marks
the inode as "deleted" and leaves the block pointers alone.
Your only hope is to "grep" for parts of your files that have been deleted
and hope for the best.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
> > By the way, there used to be undelete tool for ext2. It created a list
> > of deleted inodes with correct stat, but no names, only their inode
> > numbers. You could then pick the corect inode and give it a name, thus
> > bringing it back to life. Since ext3 is just ext2 with journal, I guess
> > it might work. It existed as a standalone tool and integrated to
> > midnight commander.
> I think there must be some other differences between ext2 and ext3, I've
> tryed e2undel and unrm, both made for ext2, and none of them found any
> deleted inode.
>
> I umonted immediately the drive, and nothing has been writen on it after
> the rm *
Maybe it's not working because you need to flush the journal before
the ext2 tool will see the inode as deleted. Alternatively, if that
is the case, perhaps by ignoring the data in the journal, the file
would not appear to be deleted.
Why not make a copy of the partition in to a file, and mount that file
using the loopback device - then you can try flushing the journal,
discarding the journal, etc.
John.
On 7 Jan 2003, Max Valdez wrote:
>
> >
> > By the way, there used to be undelete tool for ext2. It created a list
> > of deleted inodes with correct stat, but no names, only their inode
> > numbers. You could then pick the corect inode and give it a name, thus
> > bringing it back to life. Since ext3 is just ext2 with journal, I guess
> > it might work. It existed as a standalone tool and integrated to
> > midnight commander.
> >
> I think there must be some other differences between ext2 and ext3, I've
> tryed e2undel and unrm, both made for ext2, and none of them found any
> deleted inode.
>
> I umonted immediately the drive, and nothing has been writen on it after
> the rm *
>
> Thanks for the comments !
> I will keep searching !
> Max
There is a project waiting for someone who wants
to contribute. It only slightly involves the kernel,
but is quite useful.
As more people are switching from the Redmond stuff
to Linux, many have "learned" from the Redmond stuff
that `rm` isn't permanent. You can always get it
back from the `wastebasket`. Of course, the Unix
gurus know you can't. Therefore, it's time for somebody
to put a 'dumpster` in all the Linux file-systems.
Somebody should then modify `rm` and the kernel unlink
to `mv' files to the dumpster directory on the
file-system, instead of really deleting them. Then,
just like the Redmond stuff, a separate program can
be used to clear out the "dumpster" or `mv` them back.
Since sys_unlink() takes only a path-name, there isn't
a current mechanism whereby it could take a flag to
tell it to 'really' delete a file (or is there?). So,
maybe we need a new kernel function? Just hacking existing
utilities won't do the whole thing because we need programs
that delete files to transparently put them into the
dumpster as well.
The wastebasket should be called a hopper or a dumpster so
Redmond doesn't get confused and send lawyers.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
> There is a project waiting for someone who wants
> to contribute. It only slightly involves the kernel,
> but is quite useful.
> Somebody should then modify `rm` and the kernel unlink
> to `mv' files to the dumpster directory on the
> file-system, instead of really deleting them.
Another possibility would be to create a meta-device that works like a
cross between the loopback device, and WORM device, I.E. start at the
begining, and allocate sectors sequentially. Whenever a sector would
normally be overwritten, a new one is allocated instead. This way,
you could always access the filesystem as it was at any mount in time.
Hypothetically, you could do something like:
mkmetawormdevice /dev/mw0 /dev/hda2
to create a device /dev/mw0, which uses /dev/hda2 for physical
storage.
Then:
write foo to sector 0 of /dev/mw0 - actually writes foo to sector 0 of
/dev/hda2
write bar to sector 1 of /dev/mw0 - actually writes foo to sector 1 of
/dev/hda2
write foobar to sector 0 of /dev/mw0 - actually writes foobar to
sector 2 of /dev/hda2, and notes the date and time that the virtual
'overwrite' happened.
Due to the sequential nature of the writes, the data could even be
compressed quite easily.
John.
On Tuesday 07 January 2003 12:17 pm, Richard B. Johnson wrote:
> On 7 Jan 2003, Max Valdez wrote:
> > > By the way, there used to be undelete tool for ext2. It created a list
> > > of deleted inodes with correct stat, but no names, only their inode
> > > numbers. You could then pick the corect inode and give it a name, thus
> > > bringing it back to life. Since ext3 is just ext2 with journal, I guess
> > > it might work. It existed as a standalone tool and integrated to
> > > midnight commander.
> >
> > I think there must be some other differences between ext2 and ext3, I've
> > tryed e2undel and unrm, both made for ext2, and none of them found any
> > deleted inode.
> >
> > I umonted immediately the drive, and nothing has been writen on it after
> > the rm *
> >
> > Thanks for the comments !
> > I will keep searching !
> > Max
>
> There is a project waiting for someone who wants
> to contribute. It only slightly involves the kernel,
> but is quite useful.
>
> As more people are switching from the Redmond stuff
> to Linux, many have "learned" from the Redmond stuff
> that `rm` isn't permanent. You can always get it
> back from the `wastebasket`. Of course, the Unix
> gurus know you can't. Therefore, it's time for somebody
> to put a 'dumpster` in all the Linux file-systems.
> Somebody should then modify `rm` and the kernel unlink
> to `mv' files to the dumpster directory on the
> file-system, instead of really deleting them. Then,
> just like the Redmond stuff, a separate program can
> be used to clear out the "dumpster" or `mv` them back.
Actually, it already exists - It's called "lost+found".
> Since sys_unlink() takes only a path-name, there isn't
> a current mechanism whereby it could take a flag to
> tell it to 'really' delete a file (or is there?). So,
> maybe we need a new kernel function? Just hacking existing
> utilities won't do the whole thing because we need programs
> that delete files to transparently put them into the
> dumpster as well.
You also have to figure out how to communicate with an absent
user for cron/batch/background operation. After all, the user that requested
the deletion may be logged out, even if the system has only one user.
It also won't help the current situation (there is "rm -i ..." after all).
> The wastebasket should be called a hopper or a dumpster so
> Redmond doesn't get confused and send lawyers.
already named "lost+found".
This subject comes up about once every two years, and gets shot
down for the same reasons every time.
--
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]
Any opinions expressed are solely my own.
On Jan 07, 2003 17:57 +0000, John Bradford wrote:
> Maybe it's not working because you need to flush the journal before
> the ext2 tool will see the inode as deleted. Alternatively, if that
> is the case, perhaps by ignoring the data in the journal, the file
> would not appear to be deleted.
Neither - ext3 does things differently, and you cannot undelete files
from ext3. Sorry.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
On Jan 07, 2003 18:41 +0000, John Bradford wrote:
> > Somebody should then modify `rm` and the kernel unlink
> > to `mv' files to the dumpster directory on the
> > file-system, instead of really deleting them.
>
> Another possibility would be to create a meta-device that works like a
> cross between the loopback device, and WORM device, I.E. start at the
> begining, and allocate sectors sequentially. Whenever a sector would
> normally be overwritten, a new one is allocated instead. This way,
> you could always access the filesystem as it was at any mount in time.
This is commonly called a filesystem snapshot, and you can already do
it with LVM.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
> write bar to sector 1 of /dev/mw0 - actually writes foo to sector 1 of
> /dev/hda2
Sorry, I meant bar, not foo.
John.
On Jan 07, 2003 13:17 -0500, Richard B. Johnson wrote:
> Therefore, it's time for somebody to put a 'dumpster` in all the Linux
> file-systems. Somebody should then modify `rm` and the kernel unlink
> to `mv' files to the dumpster directory on the file-system, instead of
> really deleting them. Then, just like the Redmond stuff, a separate
> program can be used to clear out the "dumpster" or `mv` them back.
This is very FAQ. Please see the l-k archives for any year to find
lengthy discussions about this.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
You can try The Coroner's Toolkit. Not sure if it'll work on ext3
though.
http://www.porcupine.org/forensics/tct.html
./Owen
On Mon, 2003-01-06 at 21:58, Max Valdez wrote:
> Is there any way to revert the stupid mistyping of "rm file *" on ext3??
>
> I hope there is a way, because I dont have a backup of some files i
> mistakenly deleted
>
> Any help appreciated!
> Thanks
> Max
> --
> Max Valdez <[email protected]>
Richard B. Johnson wrote:
>
>There is a project waiting for someone who wants
>to contribute. It only slightly involves the kernel,
>but is quite useful.
>
>As more people are switching from the Redmond stuff
>to Linux, many have "learned" from the Redmond stuff
>that `rm` isn't permanent. You can always get it
>back from the `wastebasket`. Of course, the Unix
>gurus know you can't. Therefore, it's time for somebody
>to put a 'dumpster` in all the Linux file-systems.
>Somebody should then modify `rm` and the kernel unlink
>to `mv' files to the dumpster directory on the
>file-system, instead of really deleting them. Then,
>just like the Redmond stuff, a separate program can
>be used to clear out the "dumpster" or `mv` them back.
>
>Since sys_unlink() takes only a path-name, there isn't
>a current mechanism whereby it could take a flag to
>tell it to 'really' delete a file (or is there?). So,
>maybe we need a new kernel function? Just hacking existing
>utilities won't do the whole thing because we need programs
>that delete files to transparently put them into the
>dumpster as well.
>
>The wastebasket should be called a hopper or a dumpster so
>Redmond doesn't get confused and send lawyers.
>
>
>
libtrash - http://www.m-arriaga.net/software/libtrash/
It implements this functionality in userspace by intercepting libc calls
on a very configurable level (per-user/per-directory). I've tried it
out in the past and it seems to work nicely, although some temp files
dropped by programs are sometimes also dropped into the ~/trash directory..
Mike Waychison
>Cheers,
>Dick Johnson
>Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
>Why is the government concerned about the lunatic fringe? Think about it.
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
At 01:17 PM 1/7/2003 -0500, Richard B. Johnson wrote:
>There is a project waiting for someone who wants
>to contribute. It only slightly involves the kernel,
>but is quite useful.
>
>As more people are switching from the Redmond stuff
>to Linux, many have "learned" from the Redmond stuff
>that `rm` isn't permanent. You can always get it
>back from the `wastebasket`. Of course, the Unix
>gurus know you can't. Therefore, it's time for somebody
>to put a 'dumpster` in all the Linux file-systems.
i brought this up about a year ago in the list... this was
thought at that time best to be implemented in user
space.
br
On Tue, 7 Jan 2003, Andreas Dilger wrote:
> Date: Tue, 7 Jan 2003 11:55:44 -0700
> From: Andreas Dilger <[email protected]>
> To: Richard B. Johnson <[email protected]>
> Cc: Max Valdez <[email protected]>, Jan Hudec <[email protected]>,
> kernel <[email protected]>
> Subject: Re: Undelete files on ext3 ??
>
> On Jan 07, 2003 13:17 -0500, Richard B. Johnson wrote:
> > Therefore, it's time for somebody to put a 'dumpster` in all the Linux
> > file-systems. Somebody should then modify `rm` and the kernel unlink
> > to `mv' files to the dumpster directory on the file-system, instead of
> > really deleting them. Then, just like the Redmond stuff, a separate
> > program can be used to clear out the "dumpster" or `mv` them back.
>
> This is very FAQ. Please see the l-k archives for any year to find
> lengthy discussions about this.
>
Funny my gnome2 install has a wastebasket and last I checked if you open a
command shell in windows and del *.* you are screwed anyhow.
So we have exactly the same functionality windows does.
Gerhard
--
Gerhard Mack
[email protected]
<>< As a computer I find your faith in technology amusing.
On Wed, Jan 08, 2003 at 12:01:34AM -0500, Gerhard Mack wrote:
> On Tue, 7 Jan 2003, Andreas Dilger wrote:
>
> > Date: Tue, 7 Jan 2003 11:55:44 -0700
> > From: Andreas Dilger <[email protected]>
> > To: Richard B. Johnson <[email protected]>
> > Cc: Max Valdez <[email protected]>, Jan Hudec <[email protected]>,
> > kernel <[email protected]>
> > Subject: Re: Undelete files on ext3 ??
> >
> > On Jan 07, 2003 13:17 -0500, Richard B. Johnson wrote:
> > > Therefore, it's time for somebody to put a 'dumpster` in all the Linux
> > > file-systems. Somebody should then modify `rm` and the kernel unlink
> > > to `mv' files to the dumpster directory on the file-system, instead of
> > > really deleting them. Then, just like the Redmond stuff, a separate
> > > program can be used to clear out the "dumpster" or `mv` them back.
> >
> > This is very FAQ. Please see the l-k archives for any year to find
> > lengthy discussions about this.
> >
>
> Funny my gnome2 install has a wastebasket and last I checked if you open a
> command shell in windows and del *.* you are screwed anyhow.
>
> So we have exactly the same functionality windows does.
Yes. But we could do better. Since no program uses the __syscall
interface directly, wraping unlink in libc would affect all programs
including rm. It could even be done withou recompiling anything using
LD_PRELOAD.
-------------------------------------------------------------------------------
Jan 'Bulb' Hudec <[email protected]>
On 7 Jan, Richard B. Johnson wrote:
>
> tell it to 'really' delete a file (or is there?). So,
> maybe we need a new kernel function? Just hacking existing
> utilities won't do the whole thing because we need programs
> that delete files to transparently put them into the
> dumpster as well.
I think libc would be the best place to implement such a thing.
Bart
--
Bart Hartgers - TUE Eindhoven
http://plasimo.phys.tue.nl/bart/contact.html
> > > > Therefore, it's time for somebody to put a 'dumpster` in all the Linux
> > > > file-systems. Somebody should then modify `rm` and the kernel unlink
> > > > to `mv' files to the dumpster directory on the file-system, instead of
> > > > really deleting them.
[snip discussion about a temporary directory for deleted files]
> Yes. But we could do better. Since no program uses the __syscall
> interface directly, wraping unlink in libc would affect all programs
> including rm. It could even be done withou recompiling anything using
> LD_PRELOAD.
I disagree. This is the wrong goal to be aiming for.
A temporary directory for deleted files can, and should be,
implemented in userspace.
What is much more interesting is the possibility of what I described
earlier in the thread as a virtual WORM device, and what Andreas
said could be done with LVM already using filesystem snapshots -
I.E. the ability to mount the filesystem as it was at any date and
time in the past.
However, as far as I can see, LVM snapshots are a manual process - the
user has to expressly create a snapshot when they want it.
What I was thinking of was a virtual device that allocated a new
sector whenever an old one was overwritten - kind of like a journaled
filesystem, but without the filesystem, (I.E. just the journal) :-).
John.
John Bradford wrote:
>>Is there any way to revert the stupid mistyping of "rm file *" on ext3??
>
> There is no simple way, no.
>
>>I hope there is a way, because I dont have a backup of some files i
>>mistakenly deleted
>
> The only thing I can suggest is this:
>
> * Do not write anything else to the partition, and immediately
> re-mount it read-only.
>
> E.G.:
>
> mount -oremount -oro /dev/hda3
>
> * Use dd to copy the entire contents of the partition to a file on
> another partition.
>
> E.G.:
>
> dd if=/dev/hda3 of=/partition_image
>
> * Search through that file for the fragments of your lost files.
>
This is where Lazarus from The Coroner's Toolkit might come in handy.
It's designed for ext2 though, not ext3, but it might work for you
nonetheless since ext3 is basically built on top of ext2.
http://www.cert.org/security-improvement/implementations/i046.03.html
Regards,
Mike
--
Michael Milligan -- Free Agent -- [email protected]
>
> Another possibility would be to create a meta-device that works like a
> cross between the loopback device, and WORM device, I.E. start at the
> begining, and allocate sectors sequentially. Whenever a sector would
> normally be overwritten, a new one is allocated instead. This way,
> you could always access the filesystem as it was at any mount in time.
OR you can check-in your entire filesystem into CVS ;)
On Wed, 08 Jan 2003 10:57:01 GMT, John Bradford said:
> What I was thinking of was a virtual device that allocated a new
> sector whenever an old one was overwritten - kind of like a journaled
> filesystem, but without the filesystem, (I.E. just the journal) :-).
$ DIR FOO.TXT;*
FOO.TXT;1 FOO.TXT;2 FOO.TXT;2
VMS-style file versioning, anybody? ;)
> > What I was thinking of was a virtual device that allocated a new
> > sector whenever an old one was overwritten - kind of like a journaled
> > filesystem, but without the filesystem, (I.E. just the journal) :-).
>
> $ DIR FOO.TXT;*
> FOO.TXT;1 FOO.TXT;2 FOO.TXT;2
>
> VMS-style file versioning, anybody? ;)
Brilliant!
John.
On Wed, 8 Jan 2003, John Bradford wrote:
| > > What I was thinking of was a virtual device that allocated a new
| > > sector whenever an old one was overwritten - kind of like a journaled
| > > filesystem, but without the filesystem, (I.E. just the journal) :-).
| >
| > $ DIR FOO.TXT;*
| > FOO.TXT;1 FOO.TXT;2 FOO.TXT;2
| >
| > VMS-style file versioning, anybody? ;)
|
| Brilliant!
re-read the archives from 6-8 months ago.
--
~Randy
On Wed, 08 Jan 2003 13:51:18 PST, "Randy.Dunlap" said:
> On Wed, 8 Jan 2003, John Bradford wrote:
>
> | > > What I was thinking of was a virtual device that allocated a new
> | > > sector whenever an old one was overwritten - kind of like a journaled
> | > > filesystem, but without the filesystem, (I.E. just the journal) :-).
> | >
> | > $ DIR FOO.TXT;*
> | > FOO.TXT;1 FOO.TXT;2 FOO.TXT;2
> | >
> | > VMS-style file versioning, anybody? ;)
> |
> | Brilliant!
>
> re-read the archives from 6-8 months ago.
http://marc.theaimsgroup.com/?l=linux-kernel&m=101914252421742&w=2
> > | > > What I was thinking of was a virtual device that allocated a new
> > | > > sector whenever an old one was overwritten - kind of like a journaled
> > | > > filesystem, but without the filesystem, (I.E. just the journal) :-).
> > | >
> > | > $ DIR FOO.TXT;*
> > | > FOO.TXT;1 FOO.TXT;2 FOO.TXT;2
> > | >
> > | > VMS-style file versioning, anybody? ;)
> > |
> > | Brilliant!
> >
> > re-read the archives from 6-8 months ago.
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=101914252421742&w=2
So basically the idea already already exists:
http://www.netcraft.com.au/geoffrey/katie/
Brilliant! :-)
John.
> > > | > > What I was thinking of was a virtual device that allocated
> > > | > > a new sector whenever an old one was overwritten - kind of
> > > | > > like a journaled filesystem, but without the filesystem,
> > > | > > (I.E. just the journal) :-).
> > > | >
> > > | > $ DIR FOO.TXT;*
> > > | > FOO.TXT;1 FOO.TXT;2 FOO.TXT;2
> > > | >
> > > | > VMS-style file versioning, anybody? ;)
> > > |
> > > | Brilliant!
> > >
> > > re-read the archives from 6-8 months ago.
> >
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=101914252421742&w=2
>
> So basically the idea already already exists:
>
> http://www.netcraft.com.au/geoffrey/katie/
>
> Brilliant! :-)
Although I was originally thinking of doing it at sector level, rather
than at filesystem level.
John.
Hi there,
> There is a project waiting for someone who wants
> to contribute. It only slightly involves the kernel,
> but is quite useful.
Libtrash?
http://freshmeat.net/projects/libtrash/?topic_id=137
http://www.m-arriaga.net/software/libtrash/
libtrash is a shared library which implements a trash can on
GNU/Linux. When preloaded, it intercepts calls to a series of GNU libc
functions and, instead of permanently destroying files, moves them to
a "trash can".
Bye
Michael
[email protected] wrote:
> $ DIR FOO.TXT;*
> FOO.TXT;1 FOO.TXT;2 FOO.TXT;2
>
> VMS-style file versioning, anybody? ;)
This certainly lets you recover old overwritten files,
but VMS didn't protect against a "rm *". It'd
delete all revisions in one go.
Helge Hafting
Hi!
> Is there any way to revert the stupid mistyping of "rm file *" on ext3??
Yes: power it down within 5 seconds.
Or use mc undelfs feature.
Pavel
--
Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...