Hard Link broken?

[Jason]

Hello,

It seems to me Hard Links are broken in a very basic way. A Hard link is a
entry to an exist file on the same disk. It is just a pointer. One should be
able to delete a link even if the file is open via another link. Current this
does not happen. For example.

1) Make a text file
2) create a number of Hard link to it from different places.
3) Then open that file and keep it open. I did this with python shell using
open(), however any other way should work. a simple C program, whatever. You
just have to make sure the file handle is open
4) try to rename or delete any of the other Hard links you made

When doing 4) it will fail saying the file is being used by another process.
Technically it should allow the removal of the file or renaming of the link
as this is a independent action.

Is this a known issue. Would it ever be fixed?

Thanks
Jason

[malx]

Post by Jason
Hello,
It seems to me Hard Links are broken in a very basic way. A Hard link is a
entry to an exist file on the same disk. It is just a pointer. One should be
able to delete a link even if the file is open via another link. Current this
does not happen. For example.

This is not correct. A hardlink is not just a pointer. Every file
consists of one or more links, and each link is (in theory) symmetrical.
The file is deleted when its final link is deleted.

As a consequence of this, sharing for delete applies to all links
equally. If a component has opened via one link and tells the
filesystem that it cannot handle deletion, then the filesystem will not
allow deletion on the entire file.

What's confusing about this is the meaning of FILE_SHARE_DELETE has
become so tortured that people cannot use it correctly. In NT, a file
will not be deleted until the final handle is closed. Specifying
FILE_SHARE_DELETE when opening a file does not allow the file to be
"yanked" out from under an open handle. It does allow other callers to
open and mark links for deletion, which will go away when the final
handles to the deleted links are closed. Many callers do not specify
FILE_SHARE_DELETE out of fear when they really should, which gives rise
to the behavior you see below.

- M

[Jason]

Thanks,

This clarifies a lot, and tests show it works! However one bad apple not
using the flag can mess up everything for everyone.

Jason

Post by malx

Post by Jason
Hello,
It seems to me Hard Links are broken in a very basic way. A Hard link is a
entry to an exist file on the same disk. It is just a pointer. One should be
able to delete a link even if the file is open via another link. Current this
does not happen. For example.

This is not correct. A hardlink is not just a pointer. Every file
consists of one or more links, and each link is (in theory) symmetrical.
The file is deleted when its final link is deleted.
As a consequence of this, sharing for delete applies to all links
equally. If a component has opened via one link and tells the
filesystem that it cannot handle deletion, then the filesystem will not
allow deletion on the entire file.
What's confusing about this is the meaning of FILE_SHARE_DELETE has
become so tortured that people cannot use it correctly. In NT, a file
will not be deleted until the final handle is closed. Specifying
FILE_SHARE_DELETE when opening a file does not allow the file to be
"yanked" out from under an open handle. It does allow other callers to
open and mark links for deletion, which will go away when the final
handles to the deleted links are closed. Many callers do not specify
FILE_SHARE_DELETE out of fear when they really should, which gives rise
to the behavior you see below.
- M
.