If you copy a file, another instance of the file must be created and therefore it takes longer than if you move a file, when the file is not actually moved but only directories are changed. However, when people delete large quantities of files (like files in TIF or System Restore) they report that it takes a relatively long time. Shouldn't deleting involve only directory entries, and not anything actually happening to the files? If so, why does it take so long?

hello when i right click and drag a file from one hard drive to anther and off that menu click move here i beleave it actualy moves the file in this case as i move a 1.2 gig file and the hard drives used spaces on each drive changed to match.it did take some time to move these. ive delete files of the same size and it took a while.though not as long as move here did. maby this just added more confusion hope not.

It comes from the mainframe logic of how to deal with shared files. Early versions of DOS did not have support built in for shared file support. There was a module you could load that provided this (used with networks, etc..). In these versions of DOS, deleting files was simple. Flag the directory entry for it as deleted by changeing the first byte, chase the cluster chain through the FAT tables, freeing the clusters, and updating the backup FAT table. Fast. Even DEL *.* was fast because it could delete all directory entries first and then chase all the FAT chains next. Some where along the way, it was realized that with networking, TSR's and multiple tasks running under DOS, that shared file support had to become part of DOS file handling. Keep in mind, Windows was being built on top of DOS then. So it was built in, with error handling for dealing with shared files. It did not take long to realize that the fast deleting of files and shared files were not compatible. Because of the way shared files were kept track of in DOS, it could not tell for sure if all shares for a file were freed. The file control blocks could represent an interrupted update state. The solution was to make it compatible with the way its done in mainframe and multitasking systems (Windows 9x, OS/2 and others were already in use or development). To delete files, DOS now has to issue an OPEN command against the file to make sure there are no active shares or locks on the file. If none, it locks the file and Closes it, then does the delete of the directory entry, chase the cluster chain and update the backup FAT table. Then do the next file. This really slows down the DEL *.* command, as each file must have its own OPEN CLOSE DELETE sequence. Bummer for delete, but required for multitasking, networking, and real world programs. (I have noticed that under some conditions that I do not understand, Windows ME DOS delete commands seem to skip this process. But this does not happen when booting from a Windows ME diskette.)