[ksk]

>(which should not be a problem anyway).

But it is a problem. And also a difference in philosophy. NTFS gives the user and the process the guarantee that the filesystem will remain consistent. Also as a user, I have a guarantee that the file I have open, represents a file that actually exists on the file system, and not a deleted file.

[CyberShadow]

This is not relevant to the on-disk filesystem, just how the OS handles files.

The philosophy is also flawed: open a file, then create a hard link to it. You now can't delete that hard link (because the file is open), even though you just created it. This is not a problem on POSIX because it correctly distinguishes a file name (represented by a directory entry) from a file (represented by the inode).

[ksk]

Its not clear to me what "flaw" you're referring to. NTFS is reference counted and can easily accommodate other behaviors. By default, it prevents deletion, unless a process specifically permits deletion, in which case, the file can be deleted.

This makes a whole lot of sense to me as a user, because I don't want to worry about open files being possibly deleted from disk.

>open a file, then create a hard link to it. You now can't delete that hard link (because the file is open), even though you just created it. This is not a problem on POSIX because it correctly distinguishes a file name (represented by a directory entry) from a file (represented by the inode).

This is not relevant to the topic.

[CyberShadow]

It is absolutely relevant. In your very comment, you are confusing what a file and a file name is.

To rephrase: just because the FILE is open, doesn't mean that you shouldn't be able to remove a FILE NAME that references the FILE.

> as a user, because I don't want to worry about open files being possibly deleted from disk

Open files can still usually be renamed (and moved across the same volume), so a file name of an open file can still be effectively removed.