Analogy for explain...
 
Notifications
Clear all

Analogy for explaining how a file is deleted?

39 Posts
19 Users
0 Likes
4,541 Views
datacarver
(@datacarver)
Posts: 121
Estimable Member
Topic starter
 

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.

 
Posted : 11/01/2010 8:58 am
juo_siva
(@juo_siva)
Posts: 9
Active Member
 

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.

 
Posted : 11/01/2010 9:16 am
(@Anonymous)
Posts: 0
Guest
 

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?

 
Posted : 11/01/2010 9:51 am
Beetle
(@beetle)
Posts: 318
Reputable Member
 

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?

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.

 
Posted : 11/01/2010 10:28 am
(@patrick4n6)
Posts: 650
Honorable Member
 

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).

 
Posted : 11/01/2010 10:28 am
datacarver
(@datacarver)
Posts: 121
Estimable Member
Topic starter
 

Thanks guys, these are good. D

 
Posted : 11/01/2010 12:32 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

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….

wink

jaclaz

 
Posted : 11/01/2010 4:24 pm
CFP001
(@cfp001)
Posts: 36
Eminent Member
 

Depends on who you are trying to explain this to.

I use the trash can explanation. You throw away a piece of trash is the can, but is it really gone? Can you rifle through the trash and find what you are looking for, albeit sometimes a little crinkled?

 
Posted : 11/01/2010 4:25 pm
(@nigel_cro)
Posts: 29
Eminent Member
 

For NTFS

A huge warehouse, full of shelving units with many many pigeon holes. At the front of the warehouse is a small office with an old fella and a clipboard (identify the old fella as a retired policeman - usually gets a laugh from the jury)

Person wants to store 'stuff' - retired policeman takes stuff from person and stores in a pigeon hole - marks on clipboard so he can find it again.

Person no longer wants stuff stored - tells retired policeman who crosses out entry on clipboard but is too tired to actually go into the warehouse, find the 'stuff' and remove it. So it stays where it was.

Etc etc - I'm sure you get the idea - improve and adapt as required. I have used this many times in court and it always seems to go across well.

Nigel

 
Posted : 11/01/2010 4:47 pm
(@mscotgrove)
Posts: 938
Prominent Member
 

I recently had a 'heated 'discussion over a pub lunch on this topic. My friend thought the word Delete was wrong as the data was still there.

He finally accepted the Trash bin explaination that CFP001 gave.

I also describe in simple terms deleting is like throwing away the telephone directory. You can reconstruct it by phoning every number and asking who is there.

 
Posted : 11/01/2010 5:45 pm
Page 1 / 4
Share: