Hacker News Reader

Comment by jcarrano | Hacker News Reader

The guys at MS are smart enough to decompile assembly but still not enough to have a proper inode-based filesystem where you can delete files that are in use.

View on HN

It has little to do with the filesystem. Windows has OS level locks. In the case of a running executable, the mapped memory holds a lock on the exe file to prevent deleting it. This is intentional. If it didn't hold the lock then it would be possible to delete the exe file on modern versions of Windows.

Edit: since there still seems to be confusion I'll try to be clearer. On NTFS you can delete an open file. This is a solved problem. The DeleteFile API even does this by default now. The thing that prevents deletion is an OS lock. This lock only prevents deletion. Renames are still allowed.

I didn't know about the lock. What happens when you delete an open file in NTFS? Is the data still accessible for programs that have the file open? If yes, then why the lock. If not, then that's a problem.

Of course they're smart enough to have a proper inode-based filesystem. They're probably just not smart enough to swap out the file system their customers are using without their customers getting mad at them.

Allowing you to have inconsistently valid data, where a file can both exist and not exist depending on who's asking, is the opposite of smart.

I just imagined the file being part of the mob, and somebody coming to ask if it was there. The body guard just responding with a “who’s asking?”

That's why Dijkstra was against the idea of explaining CS concepts by anthromorphic analogies ig.

A file exists for those who have the access rights, and does not for everyone else.

In that case, the file exists only for the process which has already opened it.

it is a trade off

With proper capabilities (the correct way to do security), this is just normal. If you don't have the capability, the object does not exist. Capabilities can be revoked at any time too.

What do you mean, "smart enough to decompile assembly"?

That's not exactly rocket science. Anyone can do that, there's tools for that.

NTFS was doing B-trees in the 90's far before btrfs was a twinkle in someone's eye; unless some other UNIX was doing it.

NTFS was not an innovative file system. It has just used several innovations introduced earlier by HPFS.

The High-Performance File System, a.k.a. HPFS, has been included in OS/2 1.2, which was launched in November 1989.

HPFS was a very innovative file system (its chief architect was Gordon Letwin). It has introduced the Extended File Attributes. It had directories implemented with B+ trees, like IBM VSAM (introduced at some time between 1973 and 1978). It had long file names and Access-Control Lists, like the Multics FS (1965). It used cylinder groups like the Berkeley FFS (1983). It used file extents, like the SGI EFS (1988).

Among the UNIX file systems, the SGI XFS (1993, almost simultaneous with NTFS) has been the first which has added all the innovations introduced by HPFS.

Apple's HFS used a B*-tree starting in 1985.

IBM had used B+ trees for implementing the VSAM "catalogs" (IBM lingo for directories a.k.a. folders) already about a decade earlier.

Reply on news.ycombinator.com