4 ms·

> My "favorite" is the inability to delete a file that is open by another process. What does the alternative look like? Lets say a process has a file open. Le

> My "favorite" is the inability to delete a file that is open by another process. What does the alternative look like? Lets say a process has a file open. Lets say it is a really big one, like 200GB. Ok, so our disk is nearly out of space, better delete this 200GB file, problem solved right? Only not. Because now even though the file looks deleted, the process still has it open and that space is still allocated to it. So either you're hiding reality from the user, or you're preventing them from deleting a file that is in use. Windows went one way and UNIX went another.

codedokode 4y ago
Wouldn't a perfect solution be to add a function "queue file deletion after it is closed" to Windows?
- 323 4y ago
  It already has something similar, you can request for the deletion of a locked file on reboot.
  - codedokode 4y ago
    No that's not what I meant. I meant delete at the moment file becomes unused.
- smileybarry 4y ago
  It's supported if the current program allows it. "FILE_SHARE_DELETE" means your delete succeeds but gets processed once their handle closes.
  - codedokode 4y ago
    This doesn't make much sense though. Why do we need a program's permission to delete file after it has been closed?
    - smileybarry 4y ago
      It’s not after it’s been closed, it’s during. When you open a file on Windows, you can share: read, write and/or “mark to delete”. A lot of times you don’t share any (read can lead to data incoherency; write means you can go out of sync in offsets with someone else; delete might not be relevant if it’s your database file). But if you do, the file isn’t “locked” if someone else opens it for the permissions you’ve agreed to share. “FILE_SHARE_DELETE” is a little tricky because you can’t delete a file in use, because after all it’s _in use_. So instead, your request to delete puts a mark on it that prevents future opens, and completes the delete once the previously open handles all close. And except for very specific cases (PE mapping, special “on-purpose” locking, specific APIs) you can always rename/move a file in use, so combined with “FILE_SHARE_DELETE” it’s sort of equivalent except for the space not being freed immediately.
wlll 4y ago
"A process is writing to a 200GB file" There's two problems here, the process and the file, it seems you need to deal with both situations on both styles of OS. You could truncate the file (there's also a `truncate` command I have never used): cat /dev/null > somefile and let the process continue writing, or you could just `rm` the file, then either kill the process (or the other way round), or if you've got mysterious disk space usage issues you think are due to still open but deleted files you can: lsof | grep deleted I'm an ex (mostly) sysadmin and so this stuff is easy, but is obviously out of reach for "normal" users. Personally as someone who still uses Unix-like machines (Mac, servers) and Windows (games, chkdsk) and I greatly prefer the Linux/Unix way and find the Windows way frustrating.
quietbritishjim 4y ago
I've been in exactly this situation on production (with a panicked operator on the other end of the phone and any number of other applications that would've been brought down). On either platform, you end up needing to kill the offending program to release the resource. But at least on Windows you know it! On Linux you can unlink the file, realise the problem still exists, and now you've lost an avenue for figuring out the real problem.
pxc 4y ago
> Lets say a process has a file open. Lets say it is a really big one, like 200GB. Ok, so our disk is nearly out of space, better delete this 200GB file, problem solved right? Not naively intuitive, but for this you can write an empty file to the large open file with shell redirection. cat /dev/null > /path/to/big/file and that will free up the space on disk immediately. Not great, but more or less nicely handles the somewhat common runaway log file case. I get how this corner case sucks, but to me it seems so much better than the endless parade of reboots and application restarts necessitated by file locking in the Windows world.

codedokode 4y ago

Wouldn't a perfect solution be to add a function "queue file deletion after it is closed" to Windows?

323 4y ago
It already has something similar, you can request for the deletion of a locked file on reboot.
- codedokode 4y ago
  No that's not what I meant. I meant delete at the moment file becomes unused.
smileybarry 4y ago
It's supported if the current program allows it. "FILE_SHARE_DELETE" means your delete succeeds but gets processed once their handle closes.
- codedokode 4y ago
  This doesn't make much sense though. Why do we need a program's permission to delete file after it has been closed?
  - smileybarry 4y ago
    It’s not after it’s been closed, it’s during. When you open a file on Windows, you can share: read, write and/or “mark to delete”. A lot of times you don’t share any (read can lead to data incoherency; write means you can go out of sync in offsets with someone else; delete might not be relevant if it’s your database file). But if you do, the file isn’t “locked” if someone else opens it for the permissions you’ve agreed to share. “FILE_SHARE_DELETE” is a little tricky because you can’t delete a file in use, because after all it’s _in use_. So instead, your request to delete puts a mark on it that prevents future opens, and completes the delete once the previously open handles all close. And except for very specific cases (PE mapping, special “on-purpose” locking, specific APIs) you can always rename/move a file in use, so combined with “FILE_SHARE_DELETE” it’s sort of equivalent except for the space not being freed immediately.

wlll 4y ago

"A process is writing to a 200GB file" There's two problems here, the process and the file, it seems you need to deal with both situations on both styles of OS. You could truncate the file (there's also a `truncate` command I have never used): cat /dev/null > somefile and let the process continue writing, or you could just `rm` the file, then either kill the process (or the other way round), or if you've got mysterious disk space usage issues you think are due to still open but deleted files you can: lsof | grep deleted I'm an ex (mostly) sysadmin and so this stuff is easy, but is obviously out of reach for "normal" users. Personally as someone who still uses Unix-like machines (Mac, servers) and Windows (games, chkdsk) and I greatly prefer the Linux/Unix way and find the Windows way frustrating.

quietbritishjim 4y ago

I've been in exactly this situation on production (with a panicked operator on the other end of the phone and any number of other applications that would've been brought down). On either platform, you end up needing to kill the offending program to release the resource. But at least on Windows you know it! On Linux you can unlink the file, realise the problem still exists, and now you've lost an avenue for figuring out the real problem.

pxc 4y ago

> Lets say a process has a file open. Lets say it is a really big one, like 200GB. Ok, so our disk is nearly out of space, better delete this 200GB file, problem solved right? Not naively intuitive, but for this you can write an empty file to the large open file with shell redirection. cat /dev/null > /path/to/big/file and that will free up the space on disk immediately. Not great, but more or less nicely handles the somewhat common runaway log file case. I get how this corner case sucks, but to me it seems so much better than the endless parade of reboots and application restarts necessitated by file locking in the Windows world.