<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Who says UNIX file undeletion is impossible?</title>
	<atom:link href="http://www.altirium.com/blog/data-recovery/12.html/feed" rel="self" type="application/rss+xml" />
	<link>http://www.altirium.com/blog/data-recovery/12.html</link>
	<description>Discussing all aspects relating to data recovery, data conversion and data storage</description>
	<lastBuildDate>Fri, 02 Jul 2010 16:41:03 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Steven</title>
		<link>http://www.altirium.com/blog/data-recovery/12.html/comment-page-1#comment-28</link>
		<dc:creator>Steven</dc:creator>
		<pubDate>Mon, 27 Jul 2009 09:32:35 +0000</pubDate>
		<guid isPermaLink="false">http://www.altirium.com/index.php?option=com_wordpress&#038;p=12#comment-28</guid>
		<description>Even when a file does have a recognisable header and footer it can generally only be recovered in such a way if the file data is contiguous. For UFS and many other UNIX/Linux files systems does not occur in large files because they will have allocation and other file system structure data interspersed.

The recoveries on UFS file systems that we have recently been seeing were generally for large, multi gigabyte, files. UFS uses direct and indirect data allocation information, direct being pointing to file data and indirect pointing to allocation information that then points to file data. File deletion will destroy the direct allocation information when the inode is destroyed however the indirect allocation remains. The heads of the files were found manually. We were able to use file system information to refine our search rather than just trawling the entire data space. We then mapped out the used, valid, file system data and located what appeared to be the blocks of indirect allocation information for files. Following the indirection blocks we were able to rebuild the tail sections of the files and then rejoin the head and tail sections together. Please note this is a simplification of the actual analysis and work that took place.

I must stress that it is still not practicable to undertake a general un-deletion of files under UFS, this technique is for the recovery of selected file from within the UFS file system, and is dependent upon there not having been any writing back of data to the areas of disk used to store the required file, and some knowledge of the structure of the file that is required is still essential.</description>
		<content:encoded><![CDATA[<p>Even when a file does have a recognisable header and footer it can generally only be recovered in such a way if the file data is contiguous. For UFS and many other UNIX/Linux files systems does not occur in large files because they will have allocation and other file system structure data interspersed.</p>
<p>The recoveries on UFS file systems that we have recently been seeing were generally for large, multi gigabyte, files. UFS uses direct and indirect data allocation information, direct being pointing to file data and indirect pointing to allocation information that then points to file data. File deletion will destroy the direct allocation information when the inode is destroyed however the indirect allocation remains. The heads of the files were found manually. We were able to use file system information to refine our search rather than just trawling the entire data space. We then mapped out the used, valid, file system data and located what appeared to be the blocks of indirect allocation information for files. Following the indirection blocks we were able to rebuild the tail sections of the files and then rejoin the head and tail sections together. Please note this is a simplification of the actual analysis and work that took place.</p>
<p>I must stress that it is still not practicable to undertake a general un-deletion of files under UFS, this technique is for the recovery of selected file from within the UFS file system, and is dependent upon there not having been any writing back of data to the areas of disk used to store the required file, and some knowledge of the structure of the file that is required is still essential.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Haim</title>
		<link>http://www.altirium.com/blog/data-recovery/12.html/comment-page-1#comment-26</link>
		<dc:creator>Haim</dc:creator>
		<pubDate>Fri, 24 Jul 2009 19:54:04 +0000</pubDate>
		<guid isPermaLink="false">http://www.altirium.com/index.php?option=com_wordpress&#038;p=12#comment-26</guid>
		<description>It seem that you are hinting to the fact the if the deleted files have a clearly identifiable header and footer then it can be reassembled manually the old-fashion way before all the tools were available. Is that correct, or are you saying that there is a &quot;hidden&quot; or less know source of a file allocation info beside the inode?</description>
		<content:encoded><![CDATA[<p>It seem that you are hinting to the fact the if the deleted files have a clearly identifiable header and footer then it can be reassembled manually the old-fashion way before all the tools were available. Is that correct, or are you saying that there is a &#8220;hidden&#8221; or less know source of a file allocation info beside the inode?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
