Yeah tell me about it I requested a feature that BYOND sends all deleted stuff to the recycle bin.

Why BYOND only sends some stuff is beyond me.

I was actually surfing the net a while back trying to figure out how to recover lost files. It says that because Window's doesn't actually delete the file, but just makes the space available to rewrite it, you can recover lost files.

I forgot the procedure though. Didn't work for me, I installed a game over it.

Luckily, my lost files weren't too important. I just had to do a 3-day's worth of homework in a night.

Typically people have accidents.

No, it did not happen like that, I cut the file, and forgot and deleted the folder, thinking that I already pasted the files. Now go. I already fixed the problem, so there is no need for you to click your little buttons and respond.

CaptFalcon33035 wrote:

Do you seriously have nothing better to do?

Of course not. It's mid-term week.

You're a smart kid, should be making something useful or reading or something, not bothering people with worthless comments trying prove a point that you haven't all the facts about.

Well, I wasn't really trying to prove a point. It was really just a humorous comment followed by needless whining, followed by more humor and a serious answer. I do believe I have all the facts also. When a file is deleted from the Recycle Bin (as it is to be assumed in this scenario) it is completely erased from the hard drive, unless you have a program to, instead of delete files, compress them. As such, my facts are completey correct and my viewpoint stands in truth.

And yes, there is a way to recover them. He's using Windows. As long as he doesn't install something or download anything really, he should be able to get them back.

Nope.

It's good research, however, unless I'm terribly mistaken (there's a good chance of that ;-)), this is how it worked in the DOS age, and not after. The way it used to work is that files would be moved to a special part of the had drive when deleted, and could be recalled with /undelete in DOS, effectively copying them (not renaming them). When DOS went, so did that system. Your statement on the efficiency of deleting data versus copying also makes little sense. When a file is deleted, the bytes are simply magnetized and erased (I could be off here - the only undelete I'm used to is the old DOS version, which is gone), which would easily explain the speed of the removal. If the case were that the files were simply renamed, it raises a few questoins. Why are they not visible in a pure file explorer, without an OS? Why is writing to the hard drive a static speed? I could be wrong here, but the way I remember it is that undeleting died a long time ago, at least as I remember it.

A quick Google search yields a deleted file recovery tool capable of recovering an utterly ungodly number of "deleted" files from my XP system. Most of these appear to be long-deleted internet cache files, but I did empty a test file from the recycle bin just before trying it and it did indeed turn back up.

Ben G wrote:

It's good research, however, unless I'm terribly mistaken (there's a good chance of that ;-)),

I think you are quite terribly mistaken. :)

Crispy's right. When a file is deleted, it is simply removed from the master list of valid files in the filesystem. The C function call to remove a file is unlink(). What it's doing is literally removing (unlinking) the filesystem's link between the actual data and the filename in the directory hierarchy. The data is still there, but since there's no more reference to it as a proper file, it can be overwritten at any time.

I don't know about Windows, but in Unix, a single file can have multiple links to it in the directory structure. There's only one underlying copy of the data on the disk, but multiple references to it from the filesystem. If one is modified, they all reflect the change because they are all pointing to the same chunk of physical data. The way a file is moved or renamed is simply by creating a second link in the new location, then unlinking the first one. When a file has no more links to the directory structure, then it is considered deleted.

As Crispy implied, a link is a tiny amount of data, so removing it is a very quick operation.

Here's a little ascii art to illustrate the situation:
<font color="#0000ff">
&nbsp; &nbsp;file0&nbsp; &nbsp; &nbsp; file1&nbsp; &nbsp; &nbsp; file2&nbsp; &nbsp; &nbsp; file3</font>
&nbsp; <font color="#aa0000">/&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; /&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; /&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; /</font>
=<font color="#aa0000">/</font>==========<font color="#aa0000">/</font>==========<font color="#aa0000">/</font>==========<font color="#aa0000">/</font>==========
<font color="#aa0000">\_______&nbsp; |&nbsp; &nbsp; &nbsp; &nbsp;___/&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; /
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;\ |&nbsp; &nbsp; &nbsp; |&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; \| </font>[data block 1]<font color="#aa0000">&nbsp; &nbsp; &nbsp;|
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;|&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;/
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; \&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;</font>[data block 2]<font color="#aa0000">
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;\&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;</font><font color="#00aa11">|
&nbsp; &nbsp; &nbsp; &nbsp;</font>[data block 3]<font color="#00aa11">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; \
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;</font>[data block 4]

The layer on top is the directory tree. Basically just an optimized list of what files and directories exist and are accessible on the disk. The red lines are the links from the directory tree to physical data blocks on the disk. In this example, file3 is fragmented into multiple blocks, but the others are stored in continuous blocks. When I access a file, the operating system finds it in the directory tree, then follows the link to actual data on the disk.

As you can see, file0 and file1 are actually the same file because they point to the same block on the disk. Maybe they are in the middle of a move operation, and one of them will have its link to the data broken. For the other files, as soon as their red line is broken, they are deleted. For example, if file2 is deleted, its link to data block 1 will be broken, and data block 1 will be marked as free space. The data is still there until some program comes along and overwrites it to store another file's data. Until that happens, it is still recoverable by utilities that do low level searches of the filesystem for unclaimed blocks such as this.

Your statement on the efficiency of deleting data versus copying also makes little sense. When a file is deleted, the bytes are simply magnetized and erased (I could be off here - the only undelete I'm used to is the old DOS version, which is gone), which would easily explain the speed of the removal.

Crispy's statement makes perfect sense. Yours makes little sense to me. :) If all the bytes in a huge file were erased, wouldn't that take a very long time? Erasing a byte is the same as writing a 0 value to it. Removing a multi-gigabyte file takes a fraction of a second, but to do it your way means writing gigabytes of data to the disk. Last time I checked, that took much longer than a few seconds on even the fastest disks.

Why are they not visible in a pure file explorer, without an OS?

Because they have been removed from the directory listing. The directory listing is like your map of what files are represented by what bytes on the disk. When a file is no longer in that map, you need a different way of finding it where it is, or if it even still exists at all.

Why is writing to the hard drive a static speed?

The speed of disk writes varies according to many factors, such as file fragmentation level, position on the disk platters, rotation speed, seek time of the drive heads, etc. I'm not sure what you're getting at, but file removal is comparatively fast and constant because it involves changing such a small amount of data, as stated by Crispy and myself.

Ben G wrote:

Don't hard drives have built-in magnets for, essentially, sucking the information from the drive?

Not really. The only mechanism a hard drive uses to modify data is the write head. It works, essentially one bit at a time, flipping the magnetic polarity of the tiny area of the platter's surface that represents the bit in question. One direction of polarity is a 0, the other is a 1. The only way to remove the information from just one file is to modify all the bits that were part of that file. So, the write head would have to physically move over all those areas of the disk, one by one, and change their magnetic polarity. This is exactly the same thing it would do to write the original data, and the time it takes scales mostly with file size.

Of course, a huge magnet placed too close to a disk will definitely accomplish the goal of sucking information out of it. Problem is, that won't discriminate and only affect the bits from the file you want. :) There is no magic way to erase only certain bits, all at once.

In any case, the variables you stated were pretty irrelevant - what I was implying was that writing to a virgin hard drive takes the same amount of time as writing to one with use.

For the most part this is true, although unless you're dealing with a raw partition, file fragmentation still comes into play in a comparison like this.