Hi there!
If this should be the wrong mailing list please excuse me but I didn't find any better suiting.
I just subscribed after unsuccessfully searching on the net for an answer to my question.
Is it possible to undelete an accidentally deleted file that is still opened by a process?
As far as I know the file is not really deleted as long there is a file descriptor connected to the file.
I thought about something in connection with /proc/####/fd/# .
Is there any chance to get the file back to normal?
- Linux 2.6.[12]x
- ext3 or nfs (should be independent of fs, wouldn't it?)
Thanks and best regards.
Lars
PS: Sorry for my english.
On Fri, Oct 17, 2008 at 3:38 PM, Lars T?uber <[email protected]> wrote:
> Hi there!
>
> If this should be the wrong mailing list please excuse me but I didn't find any better suiting.
> I just subscribed after unsuccessfully searching on the net for an answer to my question.
>
> Is it possible to undelete an accidentally deleted file that is still opened by a process?
> As far as I know the file is not really deleted as long there is a file descriptor connected to the file.
> I thought about something in connection with /proc/####/fd/# .
> Is there any chance to get the file back to normal?
To some extent yes......
>
> - Linux 2.6.[12]x
> - ext3 or nfs (should be independent of fs, wouldn't it?)
It is tightly coupled with the filesystem. So depending on your
filesystem you may or may not get it.
LOGFS (or any log structured file system) : They generally have
snapshots or some kind of file versioning. So you can retreive it from
there.
ext2 : After deletion ext2 doesn't zero the block pointers. So it is
possible to get it from there using debugfs.
ext3 : Search google for "Carlo wood + ext3grep"
ext4 : I don't know of any method ...
You can try the /proc/****/fd/** approach . It has worked for me in
past......but that was for a running binary. I am not sure about
shellscript kind of thing. There are some other tools too to recover ,
unfortunately I don't remember the name but google should be good
enough.
Thanks -
Manish
>
>
> Thanks and best regards.
> Lars
>
>
> PS: Sorry for my english.
> --
> 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
>
Hi Manish,
"Manish Katiyar" <[email protected]> schrieb:
> > I thought about something in connection with /proc/####/fd/# .
> > Is there any chance to get the file back to normal?
>
> To some extent yes......
yes I know I could do this:
cat /proc/####/fd/32 > /dir/to/new/file.ext
but then all changes made by the process afterwards are not in the copy.
> You can try the /proc/****/fd/** approach . It has worked for me in
> past......but that was for a running binary.
Of course there is a process still running and works with a file discriptor to the deleted file.
Onother question:
Is the space of the file on the underlying block device already marked as free? Or does this happen after all processes have closed all file descriptors pointing to the file?
I really want to undo the deletion. (get a link/name connected to the root inode of the file again)
Is there a way to do this?
Thanks
Lars
On Fri, Oct 17, 2008 at 02:33:11PM +0200, Lars T?uber wrote:
> Is the space of the file on the underlying block device already
> marked as free? Or does this happen after all processes have closed
> all file descriptors pointing to the file?
No, the space on the file is not yet marked as free. *However* for
ext3 and ext4, the inode has been placed on the orphaned inode list,
so that if the system crashes, part of the journal recovery process
will at that point free the blocks.
> I really want to undo the deletion. (get a link/name connected to
> the root inode of the file again) Is there a way to do this?
Not currently using ext3/ext4, no. There would have to be an entirely
new system call or other userspace interface for something like this.
- Ted
Hi Theodore,
Theodore Tso <[email protected]> schrieb:
> On Fri, Oct 17, 2008 at 02:33:11PM +0200, Lars Täuber wrote:
> > Is the space of the file on the underlying block device already
> > marked as free? Or does this happen after all processes have closed
> > all file descriptors pointing to the file?
>
> No, the space on the file is not yet marked as free. *However* for
> ext3 and ext4, the inode has been placed on the orphaned inode list,
> so that if the system crashes, part of the journal recovery process
> will at that point free the blocks.
not that it is a way I would go, but theoretically: I could provoke a crash and mount the ext3 filesystem as ext2 and restore the file?
> > I really want to undo the deletion. (get a link/name connected to
> > the root inode of the file again) Is there a way to do this?
>
> Not currently using ext3/ext4, no. There would have to be an entirely
> new system call or other userspace interface for something like this.
Is this planned?
But a solution should be independent of the real filesystem. Because the file is still somewhere in the ram and represented in linux vfs, isn't it?
It only needs to be copied/recreated on to a (different) filesystem somehow.
Regards
Lars
On Fri, Oct 17, 2008 at 7:09 PM, Lars T?uber <[email protected]> wrote:
> Hi Theodore,
>
>
> Theodore Tso <[email protected]> schrieb:
>> On Fri, Oct 17, 2008 at 02:33:11PM +0200, Lars T?uber wrote:
>> > Is the space of the file on the underlying block device already
>> > marked as free? Or does this happen after all processes have closed
>> > all file descriptors pointing to the file?
>>
>> No, the space on the file is not yet marked as free. *However* for
>> ext3 and ext4, the inode has been placed on the orphaned inode list,
>> so that if the system crashes, part of the journal recovery process
>> will at that point free the blocks.
>
> not that it is a way I would go, but theoretically: I could provoke a crash and mount the ext3 filesystem as ext2 and restore the file?
Errr.... If I read the code correctly, once deleted the inode is added
to the orphan list and on recovery this orphan list is traversed and
iput will be called on each of the inodes. So even a crash will not
restore your inode on the contrary *it will make sure that the inode
is deleted*.
>
>> > I really want to undo the deletion. (get a link/name connected to
>> > the root inode of the file again) Is there a way to do this?
>>
>> Not currently using ext3/ext4, no.
Isn't it possible to some extent using ext3grep for ext3 ????
There would have to be an entirely
>> new system call or other userspace interface for something like this.
>
> Is this planned?
>
> But a solution should be independent of the real filesystem.
No as I said...depending on the nature of filesystem it may be write
in place or it might write to a new block every time like logfs. So
it is very much filesystem dependant.
Thanks -
Manish
>Because the file is still somewhere in the ram and represented in linux vfs, isn't it?
> It only needs to be copied/recreated on to a (different) filesystem somehow.
>
> Regards
> Lars
>
On Fri, Oct 17, 2008 at 03:39:57PM +0200, Lars T?uber wrote:
>
> not that it is a way I would go, but theoretically: I could provoke
> a crash and mount the ext3 filesystem as ext2 and restore the file?
>
Unless you then manually modify the orphan list to remove the inode
from the orphan list, the next time you mount the filesystem as ext3
the blocks will be released and the filesystem will be corrupted.
Also, if you provoke a crash, the filesystem will be marked as "needs
recovery" and ext2 will refuse to mount the filesystem.
The much simpler way would be to kill -STOP the process that owns the
file, copy it via "cat /proc/$pid/fd/$fd > rescue-file". and then kill
-9 the process if you don't want it to make any further changes.
> > Not currently using ext3/ext4, no. There would have to be an entirely
> > new system call or other userspace interface for something like this.
>
> Is this planned?
No, this is not planned. "rm is forever".
> But a solution should be independent of the real filesystem. Because
> the file is still somewhere in the ram and represented in linux vfs,
> isn't it? It only needs to be copied/recreated on to a (different)
> filesystem somehow.
No, it's not necessarily in RAM. It's on disk, in the filesystem, but
marked in such a way that if the system crashes or when the file
descriptor is closed, the inode and its contents are marked as freed
for allocation.
- Ted
Theodore Tso <[email protected]> schrieb:
> > Is this planned?
>
> No, this is not planned. "rm is forever".
Ok, Thanks anyway.
Lars