±Your Account
Membership:
New Today: 0
New Yesterday: 4
Overall: 24360
Visitors: 41±Latest Articles
· Catching the ghost: how to discover ephemeral evidence with Live RAM analysis
· Geo-tagging & Photo Tracking On iOS
· KS – an open source bash script for indexing data
· Mobile Device Geotags & Armed Forces
· Categorization of embedded system forensic collection methodologies
· Interpretation of NTFS Timestamps
· What are ‘gdocs’? Google Drive Data – part 2
· What are ‘gdocs’? Google Drive Data
· Bad Sector Recovery
· Forensic Artifact: Malware Analysis in Windows 8
· Geo-tagging & Photo Tracking On iOS
· KS – an open source bash script for indexing data
· Mobile Device Geotags & Armed Forces
· Categorization of embedded system forensic collection methodologies
· Interpretation of NTFS Timestamps
· What are ‘gdocs’? Google Drive Data – part 2
· What are ‘gdocs’? Google Drive Data
· Bad Sector Recovery
· Forensic Artifact: Malware Analysis in Windows 8
±Follow Us
±Latest Jobs
Back to top
Skip to content
Skip to menu
Back to top
Back to main
Skip to menu
Go to page 1, 2, 3, 4, 5, 6 Next
This is similar to one I use comparing the organizing of a file system to the catalogue in a library."Deleting a file is like tearing up the catalogue reference card, but the book is still on the shelf". I found it works pretty well in court because judges are familiar with the Dewey catalogues in the law libraries.
Analogy for explaining how a file is deleted?
Analogy for explaining how a file is deleted?
Posted: Sun Jan 10, 2010 10:58 pm
I would prefer some type of analogy to explain how a file is deleted. Very general and very dumbed down. Just seeing if you guys already had something.
-

datacarver - Senior Member
Re: Analogy for explaining how a file is deleted?
Posted: Sun Jan 10, 2010 11:16 pm
I just say when a file is deleted, it is not premanently removed from the storage media and can be recovered by some special tools.
_________________
sivaois.wordpress.com
_________________
sivaois.wordpress.com
-

juo_siva - Newbie
Re: Analogy for explaining how a file is deleted?
Posted: Sun Jan 10, 2010 11:51 pm
Think of a file as a labeled manila folder containing printed pages (file content). "Deleting" a file is like peeling the label off the manila folder. The original content is still there.
When "you" (the Operating System) need a new folder, you grab that now "available" unlabeled folder, add new content (effectively tossing the old pages) and stick on a new label.
Does that work?
_________________
MSc, CISSP, ACE, Licensed Private Investigator (SC)
When "you" (the Operating System) need a new folder, you grab that now "available" unlabeled folder, add new content (effectively tossing the old pages) and stick on a new label.
Does that work?
_________________
MSc, CISSP, ACE, Licensed Private Investigator (SC)
-

AWTLPI - Senior Member
Re: Analogy for explaining how a file is deleted?
Posted: Mon Jan 11, 2010 12:28 am
- AWTLPIThink of a file as a labeled manila folder containing printed pages (file content). "Deleting" a file is like peeling the label off the manila folder. The original content is still there.
When "you" (the Operating System) need a new folder, you grab that now "available" unlabeled folder, add new content (effectively tossing the old pages) and stick on a new label.
Does that work?
This is similar to one I use comparing the organizing of a file system to the catalogue in a library."Deleting a file is like tearing up the catalogue reference card, but the book is still on the shelf". I found it works pretty well in court because judges are familiar with the Dewey catalogues in the law libraries.
-

Beetle - Senior Member
Re: Analogy for explaining how a file is deleted?
Posted: Mon Jan 11, 2010 12:28 am
This is my FAT analogy:
A file system is like a filing cabinet full of hanging folders. At the front of the cabinet is list of all the files, and within which folders they are contained. When a file is deleted, the entry for that file on the list is marked as available to be used, but the folder is not emptied until you replace it with a new file.
At some point, a new file entry may be written over the entry in the list, and also at some point the folder may have it's contents taken out to make room for a new file. These events don't necessarily happen at the same time. Only once the contents of the folder have been thrown out to be replaced with a new file is the old file truly gone.
Caveats on that comment for file slack, but that's good enough for starters. I use an analogy of wiping off part of a whiteboard for file slack. Also of course you can use different security software and features, and different file systems manage this slightly differently. NTFS for example combines both the index and the file for resident files. For non-resident files, if the run lists can be completely contained in a single entry, it's much easier to recover than for example FAT if the file is fragmented. Of course, when a resident file entry is overwritten, so is the file content itself (again caveat for record slack).
_________________
Tony Patrick, B. Inf Tech, CFCE
www.patrickcomputerfor...s.com/blog
www.twitter.com/Patrick4n6
A file system is like a filing cabinet full of hanging folders. At the front of the cabinet is list of all the files, and within which folders they are contained. When a file is deleted, the entry for that file on the list is marked as available to be used, but the folder is not emptied until you replace it with a new file.
At some point, a new file entry may be written over the entry in the list, and also at some point the folder may have it's contents taken out to make room for a new file. These events don't necessarily happen at the same time. Only once the contents of the folder have been thrown out to be replaced with a new file is the old file truly gone.
Caveats on that comment for file slack, but that's good enough for starters. I use an analogy of wiping off part of a whiteboard for file slack. Also of course you can use different security software and features, and different file systems manage this slightly differently. NTFS for example combines both the index and the file for resident files. For non-resident files, if the run lists can be completely contained in a single entry, it's much easier to recover than for example FAT if the file is fragmented. Of course, when a resident file entry is overwritten, so is the file content itself (again caveat for record slack).
_________________
Tony Patrick, B. Inf Tech, CFCE
www.patrickcomputerfor...s.com/blog
www.twitter.com/Patrick4n6
-

Patrick4n6 - Senior Member
Re: Analogy for explaining how a file is deleted?
Posted: Mon Jan 11, 2010 2:32 am
Thanks guys, these are good.
-

datacarver - Senior Member
Re: Analogy for explaining how a file is deleted?
Posted: Mon Jan 11, 2010 6:24 am
Just for the record, I think at FAT as I would do for a book.
A book has an index of chapters printed on first (or last) pages with the number of page where they begin, and the actual chapters printed on actual "content" pages.
If you tear the index pages off, you cannot find anymore the beginning of each chapter without browsing through pages, but since chapters and pages are numbered and binded in numerical order, it is relatively easy to find the chapter beginning by browsing the book.
Now imagine that the book has been binded together with chapters in random order by a mad typograph.
Finding a chapter starts to be daunting, as you have to go on average through 50% of the pages to find your chapter.
But you still have pages in order and the actual chapter number and title printed.
Now what, if chapter number and first letter of the chapter title were (for a problem of ink supply in the printing machine) not printed?
You have "deleted" the files, but the files are there allright, as well as their names, with only first letter missing.
Let's go a bit further...
Now imagine that the madder assistant to the typograph has shuffled all pages and thus they are in random order.
You have a severely fragmented book and should run DEFRAG more often.
You have page numbers, thus with some time you can find everything allright, page numbers are nothing but "sector #" in the FAT chain.
Now imagine that the even madder assistant to the assistant has used fluid corrector to blank all page numbers and the whole chapter titles.
You can still probably find everything allright matching the end of the sentence on page n with the beginning on page n+1.
You can still probably assemble chapters in a "logical" order, but the name of the chapters is lost for good.
You have not only "deleted" the files, but also "formatted" the filesystem.
Now, imagine that the used ink is defective and fades away with ultraviolets (let's assume that it actually leaves no trace).
You take each page one by one and put it under a strong ultraviolet light source for an adequate amount of time.
You have "zeroed out" the disk.
Notwithstanding the evidence that our fictional ink is actually perfectly volatile, a lot of people will tell you that you need to re-print several times random books on the same pages BEFORE exposing them to the ultraviolet light source.
Welcome to the DOD or Gutmann's several passes.
You should also make sure to find another typograph, this firm seems like not very reliable.....there is a firm called NTFS that is said to be better....
jaclaz
A book has an index of chapters printed on first (or last) pages with the number of page where they begin, and the actual chapters printed on actual "content" pages.
If you tear the index pages off, you cannot find anymore the beginning of each chapter without browsing through pages, but since chapters and pages are numbered and binded in numerical order, it is relatively easy to find the chapter beginning by browsing the book.
Now imagine that the book has been binded together with chapters in random order by a mad typograph.
Finding a chapter starts to be daunting, as you have to go on average through 50% of the pages to find your chapter.
But you still have pages in order and the actual chapter number and title printed.
Now what, if chapter number and first letter of the chapter title were (for a problem of ink supply in the printing machine) not printed?
You have "deleted" the files, but the files are there allright, as well as their names, with only first letter missing.
Let's go a bit further...
Now imagine that the madder assistant to the typograph has shuffled all pages and thus they are in random order.
You have a severely fragmented book and should run DEFRAG more often.
You have page numbers, thus with some time you can find everything allright, page numbers are nothing but "sector #" in the FAT chain.
Now imagine that the even madder assistant to the assistant has used fluid corrector to blank all page numbers and the whole chapter titles.
You can still probably find everything allright matching the end of the sentence on page n with the beginning on page n+1.
You can still probably assemble chapters in a "logical" order, but the name of the chapters is lost for good.
You have not only "deleted" the files, but also "formatted" the filesystem.
Now, imagine that the used ink is defective and fades away with ultraviolets (let's assume that it actually leaves no trace).
You take each page one by one and put it under a strong ultraviolet light source for an adequate amount of time.
You have "zeroed out" the disk.
Notwithstanding the evidence that our fictional ink is actually perfectly volatile, a lot of people will tell you that you need to re-print several times random books on the same pages BEFORE exposing them to the ultraviolet light source.
Welcome to the DOD or Gutmann's several passes.
You should also make sure to find another typograph, this firm seems like not very reliable.....there is a firm called NTFS that is said to be better....
jaclaz
-

jaclaz - Senior Member
















