Words by Doug Wyatt [Fri, Aug 15, 2008 at 05:47:55AM -0500]:
>
>
> Russell Miller wrote:
>>
>>
>> On Fri, Aug 15, 2008 at 12:30 AM, Russell Miller <duskglow@gmail.com
>> <mailto:duskglow@gmail.com>> wrote:
>>
>>
>>
>> On Fri, Aug 15, 2008 at 12:17 AM, Doug Wyatt <dwyatt@sunflower.com
>> <mailto:dwyatt@sunflower.com>> wrote:
>>
>> Here's the situation - I have video file, currently open
>> in Mplayer, which I accidentally deleted from its directory.
>>
>> So, the storage and inode still exist as long as I don't
>> close the Mplayer.
>>
>> Does anyone know of a way, using available commands or via
>> system calls in a program, to reestablish a link from a
>> directory to the inode?
>>
>>
>>
>> You might try going into debugfs, finding the inode, and seeing if
>> you can tell it it's not deleted anymore. It's not actually deleted
>> until all the references are closed, so I think it might be possible
>> (I don't know the internal details of what happens when a file is
>> deleted but not closed so I may be wrong).
>>
>>
>> Oh hey. Look what I found.
>>
>> http://dag.wieers.com/blog/undeleting-an-open-file-by-inode
>>
>> Still risky but at least you won't be flying blind.
>>
>> --Russell
>>
>
> Excellent!
>
> Debugfs was exactly what I was looking for. I already had the
> inode number from lsof. Going into debugfs and using 'ln' and
> 'set_inode_field' (for incrementing the link count) took care
> of my problem.
>
> I did download the source for 'fdlink', mentioned in a comment
> on <dag.wieers.com>, and looked it over. But I decided, for
> this situation, debugfs was less likely to cause a problem.
>

There's a much easier way. Well, you don't really relink the inode but
copy the original file instead:

1. locate the open (deleted) file you want from the opening pid on /proc/$PID/fd/*
2. cp /proc/$PID/fd/$FD somewhere

--
Jose Celestino | http://japc.uncovering.org/files/japc-pgpkey.asc
----------------------------------------------------------------
"One man’s theology is another man’s belly laugh." -- Robert A. Heinlein

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Jose Celestino wrote:

*This message was transferred with a trial version of CommuniGate(r) Pro*
Words by Doug Wyatt [Fri, Aug 15, 2008 at 05:47:55AM -0500]:


Russell Miller wrote:


On Fri, Aug 15, 2008 at 12:30 AM, Russell Miller <duskglow@gmail.com
<mailto:duskglow@gmail.com>> wrote:




On Fri, Aug 15, 2008 at 12:17 AM, Doug Wyatt <dwyatt@sunflower.com
<mailto:dwyatt@sunflower.com>> wrote:

Here's the situation - I have video file, currently open
in Mplayer, which I accidentally deleted from its directory.

So, the storage and inode still exist as long as I don't
close the Mplayer.

Does anyone know of a way, using available commands or via
system calls in a program, to reestablish a link from a
directory to the inode?



You might try going into debugfs, finding the inode, and seeing if
you can tell it it's not deleted anymore. It's not actually deleted
until all the references are closed, so I think it might be possible
(I don't know the internal details of what happens when a file is
deleted but not closed so I may be wrong).


Oh hey. Look what I found.

http://dag.wieers.com/blog/undeleting-an-open-file-by-inode

Still risky but at least you won't be flying blind.

--Russell


Excellent!

Debugfs was exactly what I was looking for. I already had the
inode number from lsof. Going into debugfs and using 'ln' and
'set_inode_field' (for incrementing the link count) took care
of my problem.

I did download the source for 'fdlink', mentioned in a comment
on <dag.wieers.com>, and looked it over. But I decided, for
this situation, debugfs was less likely to cause a problem.



There's a much easier way. Well, you don't really relink the inode but
copy the original file instead:

1. locate the open (deleted) file you want from the opening pid on /proc/$PID/fd/*
2. cp /proc/$PID/fd/$FD somewhere



I think I read, somewhere, that in doing that I could end up
with garbage bytes at the end of the last block in the copy,
and would need to use the size from the original inode to
trim the copied file. Don't know if that's fact or not.

Also, by re-linking you preserve the mtime w/o hassling with
touch.

Re-linking the inode seems more elegant and satisfying after
performing a klutzy move like deleting the wrong file.

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Doug Wyatt wrote:


Jose Celestino wrote:
*This message was transferred with a trial version of CommuniGate(r)
Pro*

Words by Doug Wyatt [Fri, Aug 15, 2008 at 05:47:55AM -0500]:


Russell Miller wrote:


On Fri, Aug 15, 2008 at 12:30 AM, Russell Miller
<duskglow@gmail.com <mailto:duskglow@gmail.com>> wrote:




On Fri, Aug 15, 2008 at 12:17 AM, Doug Wyatt <dwyatt@sunflower.com
<mailto:dwyatt@sunflower.com>> wrote:

Here's the situation - I have video file, currently open
in Mplayer, which I accidentally deleted from its directory.

So, the storage and inode still exist as long as I don't
close the Mplayer.

Does anyone know of a way, using available commands or via
system calls in a program, to reestablish a link from a
directory to the inode?



You might try going into debugfs, finding the inode, and seeing if
you can tell it it's not deleted anymore. It's not actually
deleted
until all the references are closed, so I think it might be
possible

(I don't know the internal details of what happens when a file is
deleted but not closed so I may be wrong).


Oh hey. Look what I found.

http://dag.wieers.com/blog/undeleting-an-open-file-by-inode

Still risky but at least you won't be flying blind.

--Russell


Excellent!

Debugfs was exactly what I was looking for. I already had the
inode number from lsof. Going into debugfs and using 'ln' and
'set_inode_field' (for incrementing the link count) took care
of my problem.

I did download the source for 'fdlink', mentioned in a comment
on <dag.wieers.com>, and looked it over. But I decided, for
this situation, debugfs was less likely to cause a problem.



There's a much easier way. Well, you don't really relink the inode but
copy the original file instead:

1. locate the open (deleted) file you want from the opening pid on
/proc/$PID/fd/*

2. cp /proc/$PID/fd/$FD somewhere



I think I read, somewhere, that in doing that I could end up
with garbage bytes at the end of the last block in the copy,
and would need to use the size from the original inode to
trim the copied file. Don't know if that's fact or not.

Also, by re-linking you preserve the mtime w/o hassling with
touch.

Re-linking the inode seems more elegant and satisfying after
performing a klutzy move like deleting the wrong file.



I just tried to replicate your problem and cp -L worked perfectly, no
garbage bytes or anything.


Re-linking the inode is inherently dangerous, and I wouldn't recommend
it to anyone klutzy enough to remove the file they didn't really want to



--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

On Fri, 2008-08-15 at 13:42 -0500, Doug Wyatt wrote:
> Jose Celestino wrote:
> > *This message was transferred with a trial version of CommuniGate(r) Pro*
> > Words by Doug Wyatt [Fri, Aug 15, 2008 at 05:47:55AM -0500]:
> >>
> >> Russell Miller wrote:
> >>>
> >>> On Fri, Aug 15, 2008 at 12:30 AM, Russell Miller <duskglow@gmail.com
> >>> <mailto:duskglow@gmail.com>> wrote:
> >>>
> >>>
> >>>
> >>> On Fri, Aug 15, 2008 at 12:17 AM, Doug Wyatt <dwyatt@sunflower.com
> >>> <mailto:dwyatt@sunflower.com>> wrote:
> >>>
> >>> Here's the situation - I have video file, currently open
> >>> in Mplayer, which I accidentally deleted from its directory.
> >>>
> >>> So, the storage and inode still exist as long as I don't
> >>> close the Mplayer.
> >>>
> >>> Does anyone know of a way, using available commands or via
> >>> system calls in a program, to reestablish a link from a
> >>> directory to the inode?
> >>>
> >>>
> >>>
> >>> You might try going into debugfs, finding the inode, and seeing if
> >>> you can tell it it's not deleted anymore. It's not actually deleted
> >>> until all the references are closed, so I think it might be possible
> >>> (I don't know the internal details of what happens when a file is
> >>> deleted but not closed so I may be wrong).
> >>>
> >>>
> >>> Oh hey. Look what I found.
> >>>
> >>> http://dag.wieers.com/blog/undeleting-an-open-file-by-inode
> >>>
> >>> Still risky but at least you won't be flying blind.
> >>>
> >>> --Russell
> >>>
> >> Excellent!
> >>
> >> Debugfs was exactly what I was looking for. I already had the
> >> inode number from lsof. Going into debugfs and using 'ln' and
> >> 'set_inode_field' (for incrementing the link count) took care
> >> of my problem.
> >>
> >> I did download the source for 'fdlink', mentioned in a comment
> >> on <dag.wieers.com>, and looked it over. But I decided, for
> >> this situation, debugfs was less likely to cause a problem.
> >>
> >
> > There's a much easier way. Well, you don't really relink the inode but
> > copy the original file instead:
> >
> > 1. locate the open (deleted) file you want from the opening pid on /proc/$PID/fd/*
> > 2. cp /proc/$PID/fd/$FD somewhere
> >
>
> I think I read, somewhere, that in doing that I could end up
> with garbage bytes at the end of the last block in the copy,
> and would need to use the size from the original inode to
> trim the copied file. Don't know if that's fact or not.
>
> Also, by re-linking you preserve the mtime w/o hassling with
> touch.
>
> Re-linking the inode seems more elegant and satisfying after
> performing a klutzy move like deleting the wrong file.
>
I have a strong feeling that all this only works on ext2 files. For
those the mc program will undelete. But the journal of the ext3 system
will cause this to end up with garbage.
--
================================================== =====================
One person's error is another person's data.
================================================== =====================
Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam@sbcglobal.net

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

On Fri, 2008-08-15 at 13:42 -0500, Doug Wyatt wrote:
> > There's a much easier way. Well, you don't really relink the inode
> but
> > copy the original file instead:
> >
> > 1. locate the open (deleted) file you want from the opening pid
> on /proc/$PID/fd/*
> > 2. cp /proc/$PID/fd/$FD somewhere
> >
>
> I think I read, somewhere, that in doing that I could end up
> with garbage bytes at the end of the last block in the copy,
> and would need to use the size from the original inode to
> trim the copied file. Don't know if that's fact or not.

I can't imagine why that would be true. A file is a file is a file.

> Also, by re-linking you preserve the mtime w/o hassling with
> touch.

True.

> Re-linking the inode seems more elegant and satisfying after
> performing a klutzy move like deleting the wrong file.

Again true, but definitely more dodgy, and likely to depend a lot on the
specific filesystem type. The "cp" trick should work everywhere
(everywhere that supports the /proc system of course).

poc

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Patrick O'Callaghan wrote:

On Fri, 2008-08-15 at 13:42 -0500, Doug Wyatt wrote:


I think I read, somewhere, that in doing that I could end up
with garbage bytes at the end of the last block in the copy,
and would need to use the size from the original inode to
trim the copied file. Don't know if that's fact or not.



I can't imagine why that would be true. A file is a file is a file.



The file doesn't occupy the entire last sector in most filesystems.
Maybe that's what was meant originally as garbage bytes - the whole file
is there, plus the (supposedly) empty remainder of the last sector.




--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

I'd consider it a security bug to allow a user to see any bytes beyond
what was written to the file since:

1. Some ilesystems store multiple small files in the same block.
2. Some (most?) filesystems don't zero out blocks when they are
reallocated.

Either of the above could allow you to see things you shouldn't.

Wayne.


On Fri, 2008-08-15 at 15:05 -0700, Konstantin Svist wrote:
> Patrick O'Callaghan wrote:
> > On Fri, 2008-08-15 at 13:42 -0500, Doug Wyatt wrote:
> >
> >> I think I read, somewhere, that in doing that I could end up
> >> with garbage bytes at the end of the last block in the copy,
> >> and would need to use the size from the original inode to
> >> trim the copied file. Don't know if that's fact or not.
> >>
> >
> > I can't imagine why that would be true. A file is a file is a file.
> >
>
> The file doesn't occupy the entire last sector in most filesystems.
> Maybe that's what was meant originally as garbage bytes - the whole file
> is there, plus the (supposedly) empty remainder of the last sector.
>
>
>

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Words by Doug Wyatt [Fri, Aug 15, 2008 at 01:42:27PM -0500]:
>
> Jose Celestino wrote:
>> *This message was transferred with a trial version of CommuniGate(r) Pro*
>> Words by Doug Wyatt [Fri, Aug 15, 2008 at 05:47:55AM -0500]:
>>>
>>
>> There's a much easier way. Well, you don't really relink the inode but
>> copy the original file instead:
>>
>> 1. locate the open (deleted) file you want from the opening pid on /proc/$PID/fd/*
>> 2. cp /proc/$PID/fd/$FD somewhere
>>
>
> I think I read, somewhere, that in doing that I could end up
> with garbage bytes at the end of the last block in the copy,
> and would need to use the size from the original inode to
> trim the copied file. Don't know if that's fact or not.
>

No. That's not true. Where have you read that?

> Also, by re-linking you preserve the mtime w/o hassling with
> touch.
>

Ok, that can be an advantage ...

> Re-linking the inode seems more elegant and satisfying after
> performing a klutzy move like deleting the wrong file.
>

... but relinking the file can be potentially dangerous (debugfs is) and
it is not guaranteed to work on all filesystems.

--
Jose Celestino | http://japc.uncovering.org/files/japc-pgpkey.asc
----------------------------------------------------------------
"One man’s theology is another man’s belly laugh." -- Robert A. Heinlein

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

On Fri, 2008-08-15 at 15:05 -0700, Konstantin Svist wrote:
> Patrick O'Callaghan wrote:
> > On Fri, 2008-08-15 at 13:42 -0500, Doug Wyatt wrote:
> >
> >> I think I read, somewhere, that in doing that I could end up
> >> with garbage bytes at the end of the last block in the copy,
> >> and would need to use the size from the original inode to
> >> trim the copied file. Don't know if that's fact or not.
> >>
> >
> > I can't imagine why that would be true. A file is a file is a file.
> >
>
> The file doesn't occupy the entire last sector in most filesystems.
> Maybe that's what was meant originally as garbage bytes - the whole file
> is there, plus the (supposedly) empty remainder of the last sector.

The location of the last sector is irrelevant. All Unix/Linux
filesystems keep the exact size of the file in bytes as a field in the
inode (AFAIK this is a POSIX requirement). The inode hasn't disappeared,
it just doesn't have any links to it, thus the system will not allow
processes to read past the end of the allocated space, even if it's in
the middle of a sector.

This is true no matter where the file is physically.

poc

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Doug Wyatt wrote:


Jose Celestino wrote:

...
1. locate the open (deleted) file you want from the opening pid on
/proc/$PID/fd/*

2. cp /proc/$PID/fd/$FD somewhere



I think I read, somewhere, that in doing that I could end up
with garbage bytes at the end of the last block in the copy,
and would need to use the size from the original inode to
trim the copied file. Don't know if that's fact or not.

Also, by re-linking you preserve the mtime w/o hassling with
touch.


Interesting topic--I was wondering about this just the other day.

A quick test shows that Jose's approach does not suffer from either of
these problems. I'm using F9/ext3.


I can't say /how/ it works, but it works perfectly:

$ cp -p ~/Music/lib/Various Artists/Unknown/afm_St9RvdtvLeE.ogg .
$ ls -li afm_St9RvdtvLeE.ogg
233608 -rw-rw-r-- 1 joe joe 2246026 2008-07-11 21:15 afm_St9RvdtvLeE.ogg
$ audacious afm_St9RvdtvLeE.ogg &
[1] 16404
$ file /proc/16404/fd/10
/proc/16404/fd/10: symbolic link to `/home/joe/tmp/afm_St9RvdtvLeE.ogg'
$ ls -l /proc/16404/fd/10
lr-x------ 1 joe joe 64 2008-08-15 22:15 /proc/16404/fd/10 ->
/home/joe/tmp/afm_St9RvdtvLeE.ogg

$ rm afm_St9RvdtvLeE.ogg
$ ls -l /proc/16404/fd/10
lr-x------ 1 joe joe 64 2008-08-15 22:15 /proc/16404/fd/10 ->
/home/joe/tmp/afm_St9RvdtvLeE.ogg (deleted)

$ file /proc/16404/fd/10
/proc/16404/fd/10: broken symbolic link to
`/home/joe/tmp/afm_St9RvdtvLeE.ogg (deleted)'

$ cp -p /proc/16404/fd/10 afm_back_cp.ogg
$ ls -li afm_back_cp.ogg
233609 -rw-rw-r-- 1 joe joe 2246026 2008-07-11 21:15 afm_back_cp.ogg
$
[1]+ Done audacious afm_St9RvdtvLeE.ogg
$ cmp afm_back_cp.ogg ~/Music/lib/Various
Artists/Unknown/afm_St9RvdtvLeE.ogg

$

Note that the copy has the exact same size, mtime and contents as the
original file--there's no need at all to use debugfs for this.


Even though the /proc/$PID/fd/$FD appears as a symlink in the
filesystem, it doesn't behave like a normal symlink. A plain symlink
definitely won't support this sort of copy after the target file is deleted.


<Joe

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list