On a Windows NTFS file system, I have a file (say, orig.mp3). I open this file, through this path orig.mp3, in such a way that it is in use (say, by playing it in VLC).

Then I create a hard link (cmd /c mklink /h link.mp3 orig.mp3). This results in two NTFS paths pointing to exactly the same file.

Finally I try to delete linked file again (del link.mp3, or delete in Windows Explorer).

This fails with an error: "The process cannot access the file because it is being used by another process."

Why? And more importantly: how can I avoid this (apart from making sure no process has the original file in use)? Can I perhaps tell Windows to do a 'delayed delete', so that the linked file is automatically deleted when the original is no longer in use?

  • 2
    Should probably be asked on superuser. But still: movefile should be able to do the trick in any case. It's surprising that you cannot simply delete the hard link though, actually it should be a completely "unrelated" file. – Damon Nov 20 '13 at 12:30

This is quite expected behavior, the hard link is just another name for the same file. E.g., if you have file A.PDF, create hard link B.PDF to the same file, it doesn't matter whether the file is opened under the name A.PDF or B.PDF - it's still the same file, so if this file is simply opened, you can't delete either link.

The actual reason is that the name is stored as an attribute in the file record of master file table (in case of NTFS) and since the file is opened, you can't delete either link (you can't modify opened file).

In this case there's nothing like original file, since both names belong to the same (and the only one) file and both names are equal. The file is actually deleted when link count reaches zero.

  • Thanks for this answer to "Why?" As you can see, I've added my own answer on "How to avoid?" – MarnixKlooster ReinstateMonica Nov 20 '13 at 15:53
  • 4
    The "why" is incomplete; if deleting a hardlink is a modification, then so is adding one, yet you can add hardlinks to open files, just not delete or rename them. I think the "why" is just that it was decided that hardlinks can't be renamed or deleted while a file is open; an intentional design decision. – RomanSt Oct 28 '14 at 13:19

Use the FSUTIL tool to maintain the symlinks safely.


fsutil reparsepoint delete link.mp3

would remove the hardlink while preserving orig.mp3

  • 2
    But would this work on hard links? I don’t believe so. – Daniel B Oct 30 '14 at 17:03
  • Well... I got this. Error: The process cannot access the file because it is being used by another process. – ST3 Oct 2 '15 at 13:58
  • fail. same as @ST3. – Señor CMasMas Sep 18 at 20:14

As detailed in Robert Goldwein's answer, such a hard link cannot be deleted while the file is in use. However, a delayed delete turns out to be possible.

Damon's comment on this question suggests to use movefile from the Sysinternals Suite.

In my case, where I want to do this from PowerShell, I can use Lee Holmes's Move-LockedFilelink.mp3 $null, to have Windows delete the file at the next boot.

Both of the above use the Win32 MoveFileEx function with the MOVEFILE_DELAY_UNTIL_REBOOT flag.

Update: See https://gist.github.com/marnix/7565364 for a Remove-File-Eventually which I just hacked up. No guarantees. :-)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.