5 ms·

This is by design though, if another process has a lock on a file, they don't want you to delete it, since it could break another process. They actually do allo

by maldev 4y ago

This is by design though, if another process has a lock on a file, they don't want you to delete it, since it could break another process. They actually do allow it if the applications open it with the createfile flag FILE_SHARE_DELETE. Or you can do it as a transacted operation, which will delete the file "eventually". Again, it's by design, you have to be explicit if you want someone to delete a file you're using, which is honestly a better design than having it be the default with the option of locking the file like Linux does. If you really want to close it and know you could break another process but don't care(Which you should), you can use NtQueryFileInformation to get the process ID's that have the file opened, then use OpenProcess with the PID, then use NtQueryProcessInformation to get the open handles. Call DuplicateHandle on each of the handles. Then use NtQueryObject on each of them to get the name of the file, then close it.

programmer_dude 4y ago
> since it could break another process. This isn't how things work on Linux. It keeps the file "alive" as long as there is at least one process using it. Any processes which do not have the file open already will not be able to see it but those that do can keep using it. The file will be deleted when all processes release the file.
- lizknope 4y ago
  I remember getting the "text file busy" message on various Unix systems in the 1990's https://stackoverflow.com/questions/16764946/what-generates-the-text-file-busy-message-in-unix https://stackoverflow.com/questions/16764946/what-generates-...
  - mort96 4y ago
    That's about modifying files though, not deleting files. If you delete an executable that's currently running and create a new one with the same path, that's fine. If you try to modify an executable that's currently running, the kernel won't let you.
  - yencabulator 4y ago
    Not normally on delete. (Most common exception: you're trying to delete an active mountpoint.) Where most people see that is attempting to mutate a currently running executable. That's forbidden, as it would lead to executing essentially random code. You can replace what file the filename points to, with rename.
Brian_K_White 4y ago
"don't want you to delete it, since it could break another process." There is no such problem. On all the unix-likes, the kernel handles that perfectly naturally. Think of deleting a file as requesting the file deletion from the kernel rather than directly doing it like in assembly with no os. When you delete a file, the only thing that happens for sure immediately is no other process can see it in the filesystem, so no new access can be made. To all processes that didn't already have an open file handle, it is effectively deleted and no longer exists. The contents are not necessarily touched yet, and the filesysyem has not yet necessarily released the occupied inodes and blocks for any other use yet, they are all still tracked as the original file, but now invisible that nothing else except the kernel can see or access. It stays like that as long as any process anywhere has an open file handle to that file. Any process with a handle can continue using that handle as normal. If it was opened for write, it can continue to write, seek, read, etc, whatever modes the handle was created with. The kernel even keeps on coordinating between multiple processes accessing the same now-invisible file. The open file handles aren't just pacifiers, it's still a real file. But no new file handles can be opened. One by one as processes close file handles, they can no longer open new ones, until the last user has released the last handle. Only at that point the kernel frees the inodes and blocks in the filesystem making the disk blocks available for new files. No other processes break, and it's all perfectly graceful and not a problem at all. For NT not to have that is like some 70's trs-80 stuff. And holy cow that stuff you just described about querying all other processes...holy cow, not an advertisement for a great, desirable, slick system. "37 easy steps!" It's almost like you were writing a joke to say something is reasonable and then proceed to describe an absolutely laughable process.
- csmpltn 4y ago
  > "But no new file handles can be opened. One by one as processes close file handles, they can no longer open new ones, until the last user has released the last handle." Or, you know... the computer has to restart itself for some reason before the file was fully deleted, and you get a fragmented disk. If I'm asking to delete a file, I want the file deleted. I want to know whether the deletion succeeded or not. I don't want it to secretly hide in a purgatory somewhere. Is this the year of the Linux desktop already?

by maldev 4y ago

programmer_dude 4y ago

> since it could break another process. This isn't how things work on Linux. It keeps the file "alive" as long as there is at least one process using it. Any processes which do not have the file open already will not be able to see it but those that do can keep using it. The file will be deleted when all processes release the file.

lizknope 4y ago
I remember getting the "text file busy" message on various Unix systems in the 1990's https://stackoverflow.com/questions/16764946/what-generates-the-text-file-busy-message-in-unix https://stackoverflow.com/questions/16764946/what-generates-...
- mort96 4y ago
  That's about modifying files though, not deleting files. If you delete an executable that's currently running and create a new one with the same path, that's fine. If you try to modify an executable that's currently running, the kernel won't let you.
- yencabulator 4y ago
  Not normally on delete. (Most common exception: you're trying to delete an active mountpoint.) Where most people see that is attempting to mutate a currently running executable. That's forbidden, as it would lead to executing essentially random code. You can replace what file the filename points to, with rename.

Brian_K_White 4y ago

"don't want you to delete it, since it could break another process." There is no such problem. On all the unix-likes, the kernel handles that perfectly naturally. Think of deleting a file as requesting the file deletion from the kernel rather than directly doing it like in assembly with no os. When you delete a file, the only thing that happens for sure immediately is no other process can see it in the filesystem, so no new access can be made. To all processes that didn't already have an open file handle, it is effectively deleted and no longer exists. The contents are not necessarily touched yet, and the filesysyem has not yet necessarily released the occupied inodes and blocks for any other use yet, they are all still tracked as the original file, but now invisible that nothing else except the kernel can see or access. It stays like that as long as any process anywhere has an open file handle to that file. Any process with a handle can continue using that handle as normal. If it was opened for write, it can continue to write, seek, read, etc, whatever modes the handle was created with. The kernel even keeps on coordinating between multiple processes accessing the same now-invisible file. The open file handles aren't just pacifiers, it's still a real file. But no new file handles can be opened. One by one as processes close file handles, they can no longer open new ones, until the last user has released the last handle. Only at that point the kernel frees the inodes and blocks in the filesystem making the disk blocks available for new files. No other processes break, and it's all perfectly graceful and not a problem at all. For NT not to have that is like some 70's trs-80 stuff. And holy cow that stuff you just described about querying all other processes...holy cow, not an advertisement for a great, desirable, slick system. "37 easy steps!" It's almost like you were writing a joke to say something is reasonable and then proceed to describe an absolutely laughable process.

csmpltn 4y ago
> "But no new file handles can be opened. One by one as processes close file handles, they can no longer open new ones, until the last user has released the last handle." Or, you know... the computer has to restart itself for some reason before the file was fully deleted, and you get a fragmented disk. If I'm asking to delete a file, I want the file deleted. I want to know whether the deletion succeeded or not. I don't want it to secretly hide in a purgatory somewhere. Is this the year of the Linux desktop already?