Ok, I've got one that's stumping me. It's off-topic, really, except:

; cat /etc/slackware-version
Slackware 9.1.0


In my travels, on this particular system, I have accidentally unlinked a
(currently 0 bytes long, but expected to grow) file being held open by
a running process. No problem, the still-running process can continue
using the file, except no other process can.

It occured to me that ext2/3 file systems have a "debugfs" utility, and
sure enough, after reading through that manual page, it seems that I
should be able to add a link to the file, and increment the link count,
then carry on as if I had never messed it up in the first place, so ...

(please excuse the very long lines)
The file I'm interested in, as listed by lsof:

COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
innfeed 29106 news 8w REG 8,21 0 58500 /news/misc/innfeed/innfeed-dropped.A029106 (deleted)


NOTE: "Links: 1" below is a result of my own modification to the
inode, using debugfs, to increment the link count, because debugfs'
"ln" command will not do that. What I'm showing here is a more recent
attempt to get the file link in place. When I started, link count was
"0" (I had accidently unlinked the file's only link).

; mount |grep /news/misc
/dev/sdb5 on /news/misc type ext3 (rw,noexec,nodev,noatime)

# debugfs -w /dev/sdb5
debugfs: stat <58500>
Inode: 58500 Type: regular Mode: 0664 Flags: 0x0 Generation: 263182151
3
User: 9 Group: 13 Size: 0
File ACL: 0 Directory ACL: 0
Links: 1 Blockcount: 0
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x44578d07 -- Tue May 2 12:47:03 2006
atime: 0x44548ba9 -- Sun Apr 30 06:04:25 2006
mtime: 0x44548ba9 -- Sun Apr 30 06:04:25 2006
BLOCKS:

debugfs: cd innfeed
debugfs: pwd
[pwd] INODE: 58499 PATH: /innfeed
[root] INODE: 2 PATH: /
debugfs: ln <58500> innfeed-dropped.A029106
debugfs: ls
58499 (12) . 2 (12) .. 58502 (32) peer1.input
58511 (20) peer2.output 58501 (24) peer3.lock
58673 (28) peer3.output 58509 (20) peer2.lock
58506 (20) peer4.output 58503 (20) peer1.output 58512 (20) peer4.lock
58505 (20) peer5.output 58520 (24) peer6.output
58522 (16) peer7.lock 58524 (20) peer7.output
58500 (44) innfeed-dropped.A029106 58516 (44) peer6.lock
58504 (60) peer8.output 58532 (36) peer8.lock 58639 (40) peer1.lock
58698 (40) peer5.lock 58708 (456) peer9.lock
58713 (1312) peer9.output 58714 (1776) peer0.lock
0 (64) innfeed-dropped.A008364 58855 (4032) peer0.output
0 (4096) innfeed-dropped.A019508
debugfs: q


NOTE: "58500 (44) innfeed-dropped.A029106" above suggests that my
relinking the file was successful, no? Yet ...

; ls -l /news/misc/innfeed
ls: /news/misc/innfeed/innfeed-dropped.A029106: No such file or directory
total 248
-rw-rw-r-- 1 news news 166633 May 3 11:56 peer1.input
-rw-r--r-- 1 news news 6 Apr 30 06:04 peer1.lock
-rw-rw-r-- 1 news news 40960 May 3 11:56 peer1.output
-rw-r--r-- 1 news news 6 Apr 30 06:04 peer6.lock
-rw-rw-r-- 1 news news 0 Apr 30 06:04 peer6.output
-rw-r--r-- 1 news news 6 Apr 30 06:04 peer8.lock
-rw-rw-r-- 1 news news 0 May 2 20:51 peer8.output
-rw-r--r-- 1 news news 6 Apr 30 06:04 peer4.lock
-rw-rw-r-- 1 news news 0 May 3 10:37 peer4.output
-rw-r--r-- 1 news news 6 Apr 30 06:04 peer2.lock
-rw-rw-r-- 1 news news 0 Apr 30 06:04 peer2.output
-rw-r--r-- 1 news news 6 Apr 30 06:04 peer3.lock
-rw-rw-r-- 1 news news 0 May 2 07:41 peer3.output
-rw-r--r-- 1 news news 6 Apr 30 06:04 peer0.lock
-rw-rw-r-- 1 news news 0 Apr 30 06:04 peer0.output
-rw-r--r-- 1 news news 6 Apr 30 06:04 peer7.lock
-rw-rw-r-- 1 news news 0 May 1 08:20 peer7.output
-rw-r--r-- 1 news news 6 Apr 30 06:04 peer9.lock
-rw-rw-r-- 1 news news 0 Apr 30 06:04 peer9.output
-rw-r--r-- 1 news news 6 Apr 30 06:04 peer5.lock
-rw-rw-r-- 1 news news 0 May 3 08:04 peer5.output


Anyone have thoughts on this?

--
----------------------------------------------------------------------
Sylvain Robitaille syl@alcor.concordia.ca

Systems and Network analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------

On Wed, 3 May 2006 16:21:53 +0000 (UTC), Sylvain Robitaille <syl@alcor.concordia.ca> wrote:

>In my travels, on this particular system, I have accidentally unlinked a
>(currently 0 bytes long, but expected to grow) file being held open by
>a running process. No problem, the still-running process can continue
>using the file, except no other process can.

Does that mean it will write to previous file offset, thus creating a
sparse file? (similar to apache's log rotate gotcha)

>
>It occured to me that ext2/3 file systems have a "debugfs" utility, and
>sure enough, after reading through that manual page, it seems that I
>should be able to add a link to the file, and increment the link count,
>then carry on as if I had never messed it up in the first place, so ...

vi directory_name? Create a new entry -> inode <gasp> not something
I've done Speculation: in unix everything is a file...

Grant.
--
Memory fault -- brain fried

Grant wrote:

> Does that mean it will write to previous file offset, thus creating a
> sparse file? (similar to apache's log rotate gotcha)

The running process still has the file open, so all I need to do (I
believe) is create a link that points to the same inode, and tell the
file system that this inode has a link pointing to it.

I'm not sure about "apache's log rotate gotcha"; I simply HUP the
parent httpd process when I rotate my web server logs, and the process
happily closes and reopens its log files, thus using the newly created
ones. I do the same for syslog.

Unfortunately, in this case, if I HUP the process, I need to restart it.
Harmless right now, because this file is empty anyway, but if I do this
again, with a file that isn't empty, that would result in lost data, and
I'd like to avoid that.

> vi directory_name? ...

It doesn't appear to have a concept of which inode any of the listed
files point to, so unless I can create the filename pointing to the
exact inode I'm interested in, this isn't likely to help me.

> Create a new entry -> inode <gasp> not something I've done

I don't seem to be able to create new entries anyway (testing in a
different directory ...)

> Speculation: in unix everything is a file...

Yes. When you're dealing with a real file, though, that file points to
a specific inode on the disk, and if I can re-create a link to that
inode, I'll be fine.

--
----------------------------------------------------------------------
Sylvain Robitaille syl@alcor.concordia.ca

Systems and Network analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------

On Wed, 3 May 2006 16:50:18 +0000 (UTC), Sylvain Robitaille <syl@alcor.concordia.ca> wrote:

>Grant wrote:
>
>> Create a new entry -> inode <gasp> not something I've done
>
>I don't seem to be able to create new entries anyway (testing in a
>different directory ...)

Sorry, bad idea, not work for me either. -> comp.unix.shell?

There's a recent discussion on finding hardlink siblings, mentioned
inodes and files, dunno if it help...

Grant.
--
Memory fault -- brain fried

Grant wrote:

> Sorry, bad idea, not work for me either. -> comp.unix.shell?

Not likely. This isn't a shell-programming (or shell use) problem,
as much as it is a file-system internals problem.

Thanks, though.

> There's a recent discussion on finding hardlink siblings, mentioned
> inodes and files, dunno if it help...

I can do that. What I'm having difficulty with is trying create a
hardlink to an open file, where none exists (the link the file was
created with has been removed).

--
----------------------------------------------------------------------
Sylvain Robitaille syl@alcor.concordia.ca

Systems and Network analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------

Sylvain Robitaille <syl@alcor.concordia.ca> wrote:
: I can do that. What I'm having difficulty with is trying create a
: hardlink to an open file, where none exists (the link the file was
: created with has been removed).

This is not an issue I've ever played with, but it does sound reminiscent
of what the 'unrm' and 'lazarus' utilities of TCT do (bring back files which
still exist on disk but to which the link was removed). You might look into
those to see what exactly they do and if they give you any insight on how to
achieve the results interactively:

http://www.porcupine.org/forensics/tct.html

FYI, even if you kill the process, the data will still be on the disk until
the inodes are reallocated. So you could kill the process and then use one
of the file recovery utilities like those in TCT (among others) to "recreate"
the file.

On Wed, 3 May 2006 22:25:26 +0000 (UTC), Melissa Danforth <danforth@pc66.cs.ucdavis.edu> wrote:

>Sylvain Robitaille <syl@alcor.concordia.ca> wrote:
>: I can do that. What I'm having difficulty with is trying create a
>: hardlink to an open file, where none exists (the link the file was
>: created with has been removed).
>
>This is not an issue I've ever played with, but it does sound reminiscent
>of what the 'unrm' and 'lazarus' utilities of TCT do (bring back files which
>still exist on disk but to which the link was removed).

tct: MANIFEST:
....
icat - copies (cat(1)) a file by inode number.
ils - list file system inode information.

Grant
--
Memory fault -- brain fried

Melissa Danforth wrote:

> This is not an issue I've ever played with, but it does sound
> reminiscent of what the 'unrm' and 'lazarus' utilities of TCT do
> (bring back files which still exist on disk but to which the link was
> removed). You might look into those to see what exactly they do and if
> they give you any insight on how to achieve the results interactively:
>
> http://www.porcupine.org/forensics/tct.html

Ahhh ... I hadn't thought of checking out such utilities for
inspiration. Thank you, I'll have a look.

> FYI, even if you kill the process, the data will still be on the disk
> until the inodes are reallocated. So you could kill the process and
> then use one of the file recovery utilities like those in TCT (among
> others) to "recreate" the file.

That's a good point, thanks again.

The problem with killing the process though, is unless I shutdown the
parent process (nntpd) as well, effectively interrupting service, a new
one will be started faster than I can recover any stranded data (perhaps
already re-allocating those blocks). This is why I'm hoping to recover
this without resorting to killing any processes. It seems it *should*
be possible.

--
----------------------------------------------------------------------
Sylvain Robitaille syl@alcor.concordia.ca

Systems and Network analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------

Grant wrote:

> tct: MANIFEST:
> ...
> icat - copies (cat(1)) a file by inode number.
> ils - list file system inode information.

Essentially functions that I know I can get from debugfs(8).

Let me try and re-describe the situation, though, because it really
is a rather interesting problem, and I haven't yet solved it:

Process 29106 has an open file, which corresponds to inode 58500 on
the file system. The file was originally created with one hard link
(its original file name) which I have accidentally unlinked. I can
copy the contents of the file corresponding to inode 58500 into another
file until Alan Hicks' cows come home, if I want to, but that won't
help me. Process 29106 will keep writing into the file corresponding
to inode 58500, and when that process dies, those data blocks will
become available for re-use.

What I'm trying to do is recreate the link to inode 58500 while
this process is running, and holding that file open, so that when
the process dies, the file system will still have a link to the file,
and those data blocks will remain marked "in use" (and another process
will be able to use the contents of the file created by process 29106).

Does that clarify my intention at all? Melissa's suggestion that I
examine the TCT utilities for inspiration is one of those that makes me
go, "why didn't _I_ think of that?"

--
----------------------------------------------------------------------
Sylvain Robitaille syl@alcor.concordia.ca

Systems and Network analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------

On Thu, 4 May 2006 04:41:41 +0000 (UTC), Sylvain Robitaille <syl@alcor.concordia.ca> wrote:

>Does that clarify my intention at all?

Yep, you want to create a directory reference to file by inode
that is only in place while the current writing process' FD
holds a reference to the file.

Modifying the directory seems trivial at first blush, but I've
forgotten most of my systems programming learning in this area

You gonna tell the spell when you find it?

Grant.
--
Memory fault -- brain fried