Deleting hard links problem
This code fails:
[DllImport("kernel32.dll", SetLastError = true, CharSet = CharSet.Auto)] public static extern bool CreateHardLink(string lpFileName, string lpExistingFileName, IntPtr lpSecurityAttributes); static void Main() { var writer = File.CreateText("test.txt"); writer.Write("test"); writer.Flush(); CreateHardLink("hard_link.txt", "test.txt", IntPtr.Zero); File.Delete("hard_link.txt"); }
The problem here is that the hard_link.txt file is considered to be open. What I would expect to happen is that the delete would succeed in removing the directory entry, but keep the file. In other words, I would only expect it to fail if this is the last directory entry for the file (resulting in an actual delete).
For now I changed this to try to delete, but on failure, mark the file to be deletes on the next reboot.
Comments
Hi,
It's probably not "hard_link.txt" that's left open, but rather "text.txt"
This will probably do the trick.
Steven
using(var writer = File.CreateText("test.txt"))
{
}
CreateHardLink("hard_link.txt", "test.txt", IntPtr.Zero);
File.Delete("hard_link.txt");
Yeah, +1 for Steven. That should work fine.
Steven,
That is pretty much the whole point.
Deleting a hard link isn't actually deleting the file, it is removing the metadata, it should not fail.
Hi Ayende,
I agree completely with you and I find it counter intuitive as well... it's just a different way to tackle the problem.
A better workaround is to open the writer like this
var writer = new StreamWriter(File.Open("test.txt", FileMode.Create, FileAccess.Write, FileShare.Delete));
The downside is that you allow test.txt to be deleted too.
Bruno,
I don't actually control opening that file
Hi Ayende,
I think the trouble is that you're using File.Delete() to try and delete the HardLink when it's really trying you delete the underlying file.
Use the kernel's DeleteFile() method and it should delete the hardlink without the error.
Steve,
Nope, I am trying to delete the _hard link_, I don't care bout the file.
And File.Delete resolves down to Win32 DeleteFile
Hmm, well it doesn't throw the exception, but I see it doesn't delete the link file directory entry either so long as a handle to the original is in use.
Steve,
Did you check the return code and GetLastError()?
Ayende, are you ok? You haven't posted in 4 days...
Ayende, i`ve got that from msdn:
"(...)Flags, attributes, access, and sharing that are specified in CreateFile operate on a per-file basis. That is, if you open a file that does not allow sharing, another application cannot share the file by creating a new hard link to the file.(...)"
src: msdn.microsoft.com/.../aa363860%28VS.85%29.aspx
Comment preview