EFTFile1.sparseimage
in [Mac Systems]
|
From: Nick Naym on 4 Feb 2010 20:21 I was performing an "Erase Free Space" ("Zero Out Deleted Files" option) on an external drive last night. Apparently, it ran into the scheduled time my system is set to Sleep. However, this morning, my attempt to "wake" the system (via mouse or keystrokes) didn't work. Puzzled, I force-rebooted via the power button. Once rebooted, I checked the system.log, and it appeared that my system never actually went to sleep. So I assume that the "Erase Free Space" process had precedence over the Sleep command. (Why I was unable to get the screen to come on via mouse clicks/keyboard strokes this morning, therefore, puzzles me even more.) In any event, I later discovered a "Recovered files" folder in my Trash, containing a rather large (46+ GB) sparse image file ("EFTFile1.sparseimage"). I assume that it's an artifact of the interrupted (by my force-reboot) "Erase Free Space" process. But I don't understand the role of a sparse image in a process that simply overwrites deleted data. Could someone explain? -- iMac (24", 2.8 GHz Intel Core 2 Duo, 2GB RAM, 320 GB HDD) � OS X (10.5.8)
From: David Empson on 4 Feb 2010 21:30 Nick Naym <nicknaym@_remove_this_gmail.com.invalid> wrote: > I was performing an "Erase Free Space" ("Zero Out Deleted Files" option) on > an external drive last night. Apparently, it ran into the scheduled time my > system is set to Sleep. However, this morning, my attempt to "wake" the > system (via mouse or keystrokes) didn't work. Puzzled, I force-rebooted via > the power button. Once rebooted, I checked the system.log, and it appeared > that my system never actually went to sleep. So I assume that the "Erase > Free Space" process had precedence over the Sleep command. (Why I was unable > to get the screen to come on via mouse clicks/keyboard strokes this morning, > therefore, puzzles me even more.) > > In any event, I later discovered a "Recovered files" folder in my Trash, > containing a rather large (46+ GB) sparse image file > ("EFTFile1.sparseimage"). I assume that it's an artifact of the interrupted > (by my force-reboot) "Erase Free Space" process. But I don't understand the > role of a sparse image in a process that simply overwrites deleted data. > > Could someone explain? Erase free space works by creating a file which is big enough to occupy all the free space on the drive, and writing zeros (or other data patterns) into it. It makes sense that Apple happened to choose a sparse image for this, as it can be sized "bigger than possible" and disk space will only be allocated to the sparse image as it gets written. The erase mechanism will keep writing into the sparse image until it gets an error due to the disk being full, then the sparse image can be deleted. The file is probably created in a user-specific temporary items folder and it was probably moved to trash as part of the automatic cleanup during restart, which is responsible for creating Recovered Items folders in Trash if something unexpected was found in the temporary items folder. -- David Empson dempson(a)actrix.gen.nz
From: Nick Naym on 5 Feb 2010 09:15 In article 1jdg399.1clwquw1gfb2l2N%dempson(a)actrix.gen.nz, David Empson at dempson(a)actrix.gen.nz wrote on 2/4/10 9:30 PM: > Nick Naym <nicknaym@_remove_this_gmail.com.invalid> wrote: > >> I was performing an "Erase Free Space" ("Zero Out Deleted Files" option) on >> an external drive last night. Apparently, it ran into the scheduled time my >> system is set to Sleep. However, this morning, my attempt to "wake" the >> system (via mouse or keystrokes) didn't work. Puzzled, I force-rebooted via >> the power button. Once rebooted, I checked the system.log, and it appeared >> that my system never actually went to sleep. So I assume that the "Erase >> Free Space" process had precedence over the Sleep command. (Why I was unable >> to get the screen to come on via mouse clicks/keyboard strokes this morning, >> therefore, puzzles me even more.) >> >> In any event, I later discovered a "Recovered files" folder in my Trash, >> containing a rather large (46+ GB) sparse image file >> ("EFTFile1.sparseimage"). I assume that it's an artifact of the interrupted >> (by my force-reboot) "Erase Free Space" process. But I don't understand the >> role of a sparse image in a process that simply overwrites deleted data. >> >> Could someone explain? > > Erase free space works by creating a file which is big enough to occupy > all the free space on the drive, and writing zeros (or other data > patterns) into it. > Why is it necessary to create a _new_ file...and then write zeros to it? And how does this help to achieve the end result of overwriting the previously deleted data? (IOW: Why doesn't it simply perform the overwrite directly?) > It makes sense that Apple happened to choose a sparse image for this, as > it can be sized "bigger than possible" and disk space will only be > allocated to the sparse image as it gets written. The erase mechanism > will keep writing into the sparse image until it gets an error due to > the disk being full, then the sparse image can be deleted. > > The file is probably created in a user-specific temporary items folder > and it was probably moved to trash as part of the automatic cleanup > during restart, which is responsible for creating Recovered Items > folders in Trash if something unexpected was found in the temporary > items folder. -- iMac (24", 2.8 GHz Intel Core 2 Duo, 2GB RAM, 320 GB HDD) � OS X (10.5.8)
From: Jerry Bishop on 5 Feb 2010 10:53 On 2010-02-05 09:15:04 -0500, Nick Naym said: > In article 1jdg399.1clwquw1gfb2l2N%dempson(a)actrix.gen.nz, David Empson at > dempson(a)actrix.gen.nz wrote on 2/4/10 9:30 PM: > >> >> Erase free space works by creating a file which is big enough to occupy >> all the free space on the drive, and writing zeros (or other data >> patterns) into it. >> > > Why is it necessary to create a _new_ file...and then write zeros to it? And > how does this help to achieve the end result of overwriting the previously > deleted data? (IOW: Why doesn't it simply perform the overwrite directly?) Its easier and safer to create a new file and let the filesystem code in the kernel manage allocating blocks to write to, rather than having the "zero-out" program access the disk blocks directly. The new file will gobble up all the previously written-to and now freed-up disk blocks on the partition. Using the filesystem, rather than writing directly to the disk device, mitigates the problem of tracking unallocated space to make sure you don't overwrite a newly allocated block assigned to another file. The only safe way to do it at the disk device level would be to unmount the partition, kind of a problem if you are trying to clear the root partition. :-) I use the same technique on my Linux boxes, where I copy /dev/null to a file in the root directory of the filesystem I'm clearing. I take the precaution of precomputing the free space on the drive and only writing a zero-filled file that is 95% of that. Completely filling filesystems on Linux is not recommended. I don't know how Apple is deciding how many zeros to write, but I'm not surprised they used a similar technique. Jerry
|
Pages: 1 Prev: Using the shell, is my Mac 32-bit or 64-bit? Next: Apple vs. Adobe |