4 ms·

"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 natural

"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?
- Brian_K_White 4y ago
  This is a ridiculous comment. If the kernel gets to shut doen gracefully, then there is no problem at all. The file handles are closed when the processed are killed and the filesystem is unmounted in a consistent state. If the kernel does not get to shut down gracefully (crash or power loss) the filesystem is left no more or less inconsistent than by any other kind of ongoing activity (nothing worse about a pending free-these-blocks vs a pending anything else), and is cleaned up by fsck or by the journal if there is one. Either way the file is finished being deleted on reboot because no processes have open handles and the kenel and the fs know that those blocks are deleted. The last on-disk state of those inodes was that the blocks are not used by any normal file. They are marked pending to be freed but hadn't been freed yet, but now during the mounting process at boot there are no processes that own them, so they are freed. It's no different than the normal process if there were no power loss. There is no such problem. As for "some kind of purgatory" and "I want to know it's done now" these imply ignorance of what a multi process operating system is, what it needs to do, the basic job of a kernel, etc. Not just in linux but nt and any other os that allows multiple concurrent processes. It's the primary job of the kernel to manage exactly such coordination between a process, another process, and the hardware. Slightly virtualizing things like ram and disk is the very job the kernel is there to do, and what makes multiple concurrent processes even posible. When you delete a file from a process and get your return from that syscall, it IS "really done right now" as far as that process and all other processes are concerned, and "from your point of view" is as "real" as anything ever gets for any process. The fact that some other process can continue reading and writing to a file handle you no longer care about is none of your business any more, and your intent that the file no longer exist in the filesystem so that it could be created again without conflict, or so that it no longer appears in listings, all does happen as you requested, and immediately. If you had a file named foo, and you needed to delete that because you need to create a directory named foo, you can do that. It happens exactly as you need, even though some other process now has a file handle open to some invisible file that used to be named foo. That other file handle is just not your problem any more. It's as if the other process simply opened a new temp file in some other firectory that has nothing to do with you.
maldev 4y ago
If you read my comment, you can see in the first few words I mention how you can do a delete transaction and it will delete it when it's not being used anymore. Or you can also just open the file with the share delete flag and it will allow the same. And linux doesn't handle it perfectly, you see errors like "text file busy". I don't get why you chose to argue how the non recommended, brute force method, is lengthy. It's not intended to be used and was mainly just to show you can, and there's nothing stopping you. Why is explicitness bad? Would you rather have those weird errors on linux where it's open by default? Or have it where the program author has to say "Yes, this file is fine to be deleted while i'm using it".
- Phemist 4y ago
  I'm just going by the comments of others but: "Yes, this file is fine to be deleted while i'm using it" is fine if all processes play nice, which apparently Windows Defender _does not_. Edit: likely Windows Defender couldn't work if it did? So, in order to consistently delete a file without triggering the file lock, you need to use the work-around. I'm just guessing here, but wouldn't Windows Defender need to be some privileged process (as it's e.g. an anti-virus) where then this file-locked file deletion process would be impossible to perform? Otherwise, a computer virus could just keep killing the Windows Defender file handler, making it impossible to read its files and keeping Windows Defender from performing its duty.
  - maldev 4y ago
    Exactly, the developers of Defender decided it needed to lock the file, arguably for alot of reasons. To prevent tampering etc, it's an antivirus, it doesn't want you to be able to bypass a scan of a file, or change it. Windows has things like Datastreams(Which come from Mac), so the same "file", can actually have two different files in it, and require different file openings. IE, "Foo.exe" and "Foo.exe:MALWARE" would be completely different file contents, despite both being foo.exe. And OpenFile("Foo.exe"), would not open foo.exe:MALWARE. Alot of the confusion comes from people not understanding the functionality. Delete file means "Delete it now" on windows(ignoring slack space). But on linux it means "Queue up the file to be deleted". Windows also has this, but it's going to be a transacted operation, which is literally called DeleteFileTransacted vs DeleteFile, so the Kernel sees noone is using it and then will delete it. And honestly, if you go up to any lay person and ask them "What does 'DeleteFile'" do. They'll probably respond it deletes the file. Not queues it up for deleted, but other people can still access it. So I think the windows verbage makes more sense, with another function appending Transacted to it, which signifies it will be done eventually.

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?

Brian_K_White 4y ago
This is a ridiculous comment. If the kernel gets to shut doen gracefully, then there is no problem at all. The file handles are closed when the processed are killed and the filesystem is unmounted in a consistent state. If the kernel does not get to shut down gracefully (crash or power loss) the filesystem is left no more or less inconsistent than by any other kind of ongoing activity (nothing worse about a pending free-these-blocks vs a pending anything else), and is cleaned up by fsck or by the journal if there is one. Either way the file is finished being deleted on reboot because no processes have open handles and the kenel and the fs know that those blocks are deleted. The last on-disk state of those inodes was that the blocks are not used by any normal file. They are marked pending to be freed but hadn't been freed yet, but now during the mounting process at boot there are no processes that own them, so they are freed. It's no different than the normal process if there were no power loss. There is no such problem. As for "some kind of purgatory" and "I want to know it's done now" these imply ignorance of what a multi process operating system is, what it needs to do, the basic job of a kernel, etc. Not just in linux but nt and any other os that allows multiple concurrent processes. It's the primary job of the kernel to manage exactly such coordination between a process, another process, and the hardware. Slightly virtualizing things like ram and disk is the very job the kernel is there to do, and what makes multiple concurrent processes even posible. When you delete a file from a process and get your return from that syscall, it IS "really done right now" as far as that process and all other processes are concerned, and "from your point of view" is as "real" as anything ever gets for any process. The fact that some other process can continue reading and writing to a file handle you no longer care about is none of your business any more, and your intent that the file no longer exist in the filesystem so that it could be created again without conflict, or so that it no longer appears in listings, all does happen as you requested, and immediately. If you had a file named foo, and you needed to delete that because you need to create a directory named foo, you can do that. It happens exactly as you need, even though some other process now has a file handle open to some invisible file that used to be named foo. That other file handle is just not your problem any more. It's as if the other process simply opened a new temp file in some other firectory that has nothing to do with you.

maldev 4y ago

If you read my comment, you can see in the first few words I mention how you can do a delete transaction and it will delete it when it's not being used anymore. Or you can also just open the file with the share delete flag and it will allow the same. And linux doesn't handle it perfectly, you see errors like "text file busy". I don't get why you chose to argue how the non recommended, brute force method, is lengthy. It's not intended to be used and was mainly just to show you can, and there's nothing stopping you. Why is explicitness bad? Would you rather have those weird errors on linux where it's open by default? Or have it where the program author has to say "Yes, this file is fine to be deleted while i'm using it".

Phemist 4y ago
I'm just going by the comments of others but: "Yes, this file is fine to be deleted while i'm using it" is fine if all processes play nice, which apparently Windows Defender _does not_. Edit: likely Windows Defender couldn't work if it did? So, in order to consistently delete a file without triggering the file lock, you need to use the work-around. I'm just guessing here, but wouldn't Windows Defender need to be some privileged process (as it's e.g. an anti-virus) where then this file-locked file deletion process would be impossible to perform? Otherwise, a computer virus could just keep killing the Windows Defender file handler, making it impossible to read its files and keeping Windows Defender from performing its duty.
- maldev 4y ago
  Exactly, the developers of Defender decided it needed to lock the file, arguably for alot of reasons. To prevent tampering etc, it's an antivirus, it doesn't want you to be able to bypass a scan of a file, or change it. Windows has things like Datastreams(Which come from Mac), so the same "file", can actually have two different files in it, and require different file openings. IE, "Foo.exe" and "Foo.exe:MALWARE" would be completely different file contents, despite both being foo.exe. And OpenFile("Foo.exe"), would not open foo.exe:MALWARE. Alot of the confusion comes from people not understanding the functionality. Delete file means "Delete it now" on windows(ignoring slack space). But on linux it means "Queue up the file to be deleted". Windows also has this, but it's going to be a transacted operation, which is literally called DeleteFileTransacted vs DeleteFile, so the Kernel sees noone is using it and then will delete it. And honestly, if you go up to any lay person and ask them "What does 'DeleteFile'" do. They'll probably respond it deletes the file. Not queues it up for deleted, but other people can still access it. So I think the windows verbage makes more sense, with another function appending Transacted to it, which signifies it will be done eventually.