> > If a file is still open, it is not deleted till the last application
> > using it has closed it. If you rename the file, it will continue writing
> > to the renamed file.
> This just sparked an "oh" response.
>
> If I understand correctly, the web server opens the file but uses the
> disk address of the file to know where to write the log info. This
> disk address is in the inode. If I delete that file and then re-
Not exactly. An Inode is more like a pointer to a file control
block. (FCB) The name is a value stored in a string within the FCB
structure pointed to by the inode. If you do an ls -i, you will see the
inode numbers next to the names.
> create it then I am creating a new inode for this "new" file. I have
> not deleted the old inode ... or did I? If I did not then that means
You just changed the contents of a string in the FCB, that's all.
The program is using the inode as a pointer.
> that the data must be written on the disk but to a space which is
> identified only by the "disk addresses" which leads me to believe
> that I could recover the data.
The inode has been flagged as deleted. When the last program using
the inode closes the file, all the sectors used by the inode will be put
on the free chain for recycling. You could do a raw read of the disk,
using /dev/sda## (or /dev/hda## if IDE,) but it would be iffy. I've done
it... and stitched deleted web server logs back together again by analyzing
the date codes within the web server records, then subjecting them to
rigorous tests, but it was MESSY, UGLY, etc. (Lost three years of web
logs, so I kind of wanted to recover them...) Do a block read, index the
block for known markers, and discard if the markers do not exist. Then...
well, you need something to check for date order. (if it was a sequential
file, mine were sorted by IP number or domain name...)
> Ummm .... I think you would say that an inode is not deleted until
> the last application that was using it had closed. Why would the
> webserver not lock the file? It should prevent someone from changing
> the file while it was still using it.
You probably have four to eight web server clone tasks capable of
writing records to the file -- more if this is a busy site.
> But what can you do to this log file that would cause the creation of
> a new inode to describe the file? I am certain that the person who
killall -HUP httpd
> caused this did not delete the log file. They simply did something
> that caused the webserver to stop writing to the log file. Restarting
> the webserver of coursed solved everything.
They caused the file to be renamed or flagged as deleted. As long
as the web server task was alive, it was writing the data to the old
inode. And then, nothing wanted the inode. OR, perhaps the inode is
still there under a different name?
[EMAIL PROTECTED] ------------------ [EMAIL PROTECTED]
----------------------- IMAGINEERING --------------------------
----------------- Every mouse click, a Vote -------------------
---------- Do they vote For, or Against your pages? -----------
----- What people want: http://www.mall-net.com/se_report/ ----
---------------------------------------------------------------
____________________________________________________________________
--------------------------------------------------------------------
Join The NEW Web Consultants Association FORUMS and CHAT:
Register Today at: http://just4u.com/forums/
Web Consultants Web Site : http://just4u.com/webconsultants
Give the Gift of Life This Year...
Just4U Stop Smoking Support forum - helping smokers for
over three years-tell a friend: http://just4u.com/forums/
To get 500 Banner Ads for FREE
go to http://www.linkbuddies.com/start.go?id=111261
---------------------------------------------------------------------
