boot problem, disk mess.. thinking of suicide.

[Erik Wikström]

4$0$786$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <9401072f0609280518n5c6d6f74gca37c5b186393b73 at xxxxxxxxxxxxxx>
In-Reply-To: <9401072f0609280518n5c6d6f74gca37c5b186393b73 at xxxxxxxxxxxxxx>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 22
Message-ID: <451bcb02$0$788$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
NNTP-Posting-Host: 81.234.112.119
X-Trace: 1159449347 crater_reader.dragonflybsd.org 788 81.234.112.119
Xref: crater_reader.dragonflybsd.org dragonfly.users:7459

On 2006-09-28 14:18, Vladimir Mitiouchev wrote:
> 28 Sep 2006 11:41:59 GMT, Oliver Fromme <check+j6auf200rs4zrznn at xxxxxxxxxx>:
>> However, fsck can neither detect nor repair any damage in
>> the contents of files.
> So, do You have any simple ideas how to detect damage in files?
> Checksums, or sth? Something simple and working. And automagic ;-) Is
> there any solutions? Fast and reliable? If not, maybe i should write
> one? Something like background checking of checksums after fsck, and
> doing such checksums for any data written to disk.. But should I
> integrate it into filesystem? Or that's stupid?

I believe that tripwire and other IDS uses checksums to detect when 
files change. What you could do is that after you make a backup you 
calculate checksums for all files and store them away somewhere, they 
you can easily (though time-consuming) check for files that have changed 
since last backup. I suppose that you could make an app that runs as 
daemon checking the files, perhaps you can even get some notification 
from kernel when files change. What would have been really nice in this 
situation is ZFS, which has built-in checksums.

--
Erik Wikström