According to my understanding of the Windows filesystem, a program can read a file according to its path, if this path is changed, then whatever program used to read this file, can no longer do so. This would mean that, to any programs in the windows system that depend on a file, the consequences of deleting and renaming a file must be the same.

The specific case that this answer depends on is an embedded system running on Windows 2000, the service provider manual guides the user to delete the files inside a folder. As a wary user, I simply copied the files to a path called "folder_backup", and left the folder empty.

During this operation, the system regressed and was unable to function correctly. So the service provider that wrote the manual was called. Their diagnostic was that the database was corrupted because there were 2 databases in parallel, pointing to "folder_backup" as the second database. To my understanding, the files inside "D:/folder_backup" would have been inert, barring the exceptional case of a program looking for folders starting with "folder" or reading all contents in the "D:/" file.

In what non-obscure ways can a renamed file still be accessed by a system, that would have otherwise been impossible were the file deleted?

  • 1
    Did you in fact copy the files (having two copies at some point and then deleting the original) or simply move them?
    – GSerg
    Commented Jun 15, 2019 at 10:43
  • 1
    Was the system running at the time reading those databases? It is possible on Windows (Linux too) to copy files while they are open (depending on the application opening the files in certain "modes"). This would probably result in corrupt copies, BTW.
    – davidbak
    Commented Jun 16, 2019 at 0:04
  • @davidbak Negative, the application was closed when renaming the files.
    – TZubiri
    Commented Jun 16, 2019 at 4:40
  • @GSerg I believe I renamed the folder and then allowed the application setup to recreate it.
    – TZubiri
    Commented Jun 16, 2019 at 4:41
  • Compare with Unix filesystems, where the ID of a file is an integer, and a file name is really only a mapping from names to ID, and a file is not deleted until it has no names and no processes have it open. Renaming a file in Unix adds a new name mapping, then removes the old name, so at no point is the file deleted.
    – Raedwald
    Commented Jul 5, 2019 at 17:33

2 Answers 2


Spoilt for choice really.

  • Wow, I didn't expect there to be so many ways to break something by renaming a file. Thanks!
    – TZubiri
    Commented Jun 15, 2019 at 4:09
  • @wizzwizz4 2000 is NT
    – zdimension
    Commented Jun 15, 2019 at 15:41

A renamed file can still be accessed by another program.

  • One way a renamed file can still be accessed by another program is an environment variable that is set to the new file path by the same program that renamed the file. The program that wants to access said file uses the environment variable for the file path instead of a fixed internally set file path.

  • Another way is for the file to be the only file in a specific folder. The program that wants to use this file knows that there should never be more than one file in that specific folder, but knows that the filename may change but the directory it belongs in will stay the same. The program simply just uses the first file it can find in that folder, which should always be that file. However this is not good practice and you are better off with an environment variable.

Failing that, some programs will automatically ask the user to locate the file before continuing to execute it's code

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .