11 ms·

> superbly coherent design [...] NT is pretty neat, and I would dare say, beautiful in some places Practically, though, it's a shit show. My "favorite" is the

• herio 4y ago
  > Practically, though, it's a shit show. I usually put it as "Deep inside windows is a really beautiful OS just screaming to be let out from under all that junk on top." The NT kernel isn't that bad, different from unix for sure but still good. It then just keeps getting progressively worse as you go upwards in the stack from there.
• AnIdiotOnTheNet 4y ago
  > 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.
• 323 4y ago
  > My "favorite" is the inability to delete a file that is open by another process Because of this Linux "feature" I experienced data loss - I zipped a file and deleted it, but the process which created it was still writing to it. But all the data that it wrote now ended up in the void since the file didn't exist anymore. And there was no error/warning that the process was writing to a non-linked file, so I discovered the data loss much later.
  • codedokode 4y ago
    Because the file was actually existing, but removed from directory list.
    • iso1210 4y ago
      And you can still access it while it's open from the /proc directory
  • P5fRxh5kUvp2th 4y ago
    you CAN lock files under linux, it's just not the default.
    • shakow 4y ago
      But locks are suggestive, not mandatory. So if the other process does not take them into account, they just have no effect.
      • chasil 4y ago
        Mandatory locking has profound security impacts. I can update glibc or other core system libraries on Linux without rebooting. Processes using the old library will show "(deleted)" in their /proc/self/maps files, but they will continue to use the old code. New processes will use the new library, and downtime was not required. This is not possible on Windows because of mandatory locking on core system libraries. As a consequence, Windows must reboot for every Patch Tuesday. There are only a few places that Linux has mandatory locking, and this is a good thing. Here is a script that will show you all the deleted libraries that are still in use on Linux: # cat stale_libraries.sh #!/bin/sh awk '$NF=="(deleted)" && $(NF-1) ~ /[.]so/ { sub(/;.*$/,"",$(NF-1)) print $(NF-1), $NF}' /proc/*/maps | sort -u Here is a script that will show you all PIDs that are running with deleted libraries: # cat stale_programs.sh #!/bin/sh grep '[.]so.*deleted)' /proc/*/maps | sed 's/[:][^/]*//' | sort -u | while read -r line do pid=${line#/} pid=${pid#*/} pid=${pid%%/*} xargs -0 printf '%s ' < "/proc/$pid/cmdline" | sed 's/[ ]$//' printf :%s\\n "$line" done Some of the maps files can only be read by root.
• elzbardico 4y ago
  First is a design decision. The second can be easily solved by configuring the appropriate exclusions on Windows Defender.
  • scbrg 4y ago
    Can I, as an application developer, configure a user's exclusion list in Windows Defender? If yes - that sounds insane! If no - it doesn't really help, then, does it? The complaint was that an application developer cannot create a file and then just move/remove it when they please. I'm neither a Windows user nor Windows dev, so I might be missing something.
    • elzbardico 4y ago
      He writes compilers and developers tools. There are plenty of other developers of compilers and developer tools for Windows who apparently don't see this as big hassle because probably they understand that Windows have other ways of doing things differently from the way he is used to doing in Unix. If his application can only work by creating and deleting files as soon as they are created, then it makes sense for him to point his users to the appropriate documentation.
• P5fRxh5kUvp2th 4y ago
  I think that file locking was a decision made with good intentions, but it's probably one of the single biggest mistakes in the windows ecosystem. And I understand people will argue for it because it does have some utility, but not near enough to pay for the all the damage it's done to people's time.
• 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
• smileybarry 4y ago
  > Combine this with Windows Defender that scans every file that your application creates, and now you have no reliable way of deleting or moving your files. This doesn't happen for years now due to "opportunistic locks" -- when you open a file being used by an app which support oplocks (i.e.: usually antiviruses), they get a blocking notification and can release the file. They can hold the notification (and stall the requesting application) until they're done, close their handle, and the other app's open succeeds.
  • cma 4y ago
    Is this where all the stalls during big compiles come from?
    • indrora 4y ago
      That's probably your disks cache catching up with what you've done. NTFS likes making sure that disks flush their caches regularly, and congestion caused by cache bloating makes it harder. Getting an nvme (or better, while you can, Optane) SSD for compilation on is a good start for improving your build times.
  • xwolfi 4y ago
    Sweet child, he reads the documentations but doesnt use it. I concur with op, to this day, deleting a fucking file in Windows is an unbelievable chore compared to all their competitors. I tried today, nope, couldn't. But you dont care, obv you dont use it.
    • kevin_thibedeau 4y ago
      Use Shift-Del to bypass the performance shitshow that is the recycle bin.
    • smileybarry 4y ago
      I use Windows Defender on several PCs, and have used for years. All are kept up to date on Windows 11 (and prior, Windows 10) and not “modded” to disable telemetry etc. I haven’t had a “locked by Defender” error in at least 5 years, and I would say more if I could remember the last time I did. I’m also developing a(n existing) product that actually uses oplocks, so I’m speaking from experience here.
• dboreham 4y ago
  > inability to delete a file that is open by another process otoh if you have never encountered Unix, you might be surprised that it's even possible to delete a file currently open by another process.
  • BenjiWiebe 4y ago
    And if someone is more familiar with nix then windows, trying to delete a directory in Windows can be a teeth-grinding frustration. I don't care* if this file 3 levels down is still open by some background process... If I cared, I wouldn't be trying to delete it!
• cshokie 4y ago
  Windows has the concept of OpLocks on files, which open the file but can be broken by other access. When used properly that should prevent antivirus from ever preventing file deletion. The deletion would break the lock that antivirus has open.
  • mike_hearn 4y ago
    But apps have to use it. An example of an app that apparently doesn't is Explorer. Another example: cmd.com. So if you have a shell or explorer window opened in a directory, and an app tries to delete or move it, that app will die. It might be better for Explorer to notice and go up to the next nearest available directory.
    • jaywalk 4y ago
      > It might be better for Explorer to notice and go up to the next nearest available directory. But... that's what it does?
      • mike_hearn 4y ago
        At least last year I was seeing problems where having Explorer open in a directory would block an app from moving or deleting that directory. So if it was using oplocks then, it didn't seem to be working.
• phendrenad2 4y ago
  > Practically, though > someone who works on a C/C++ build toolchain Pick one. No seriously, tradeoffs have to be made, and I don't think "people who work on build automation" are the intended main use case for Windows Home Edition.
• yamtaddle 4y ago
  I recently discovered that Linux handles processes holding files open a little differently from FreeBSD, too, when I tried to unmount a ZFS volume. Something had ahold of a file on it, so I couldn't unmount it—on FreeBSD you can just say "I want all programs that are preventing this to fuck off and, if they're so inclined, to crash"—and ZFS provides a flag to do just that—and go on with your day, but Linux evidently won't let you (I ended up on some ZFS mailing list archive to confirm this was the case and I wasn't just holding it wrong). You have to go track the process(es) down and kill it(/them) yourself, not unlike how you can't delete a file that's in use on Windows and have to go kill the processes. It was faster to just reboot the damn machine than to do that (a very Windows solution). [EDIT] It may have been a ZFS export operation, not exactly an unmount? I can't recall for sure. Point is, Linux made you go find and kill the relevant processes yourself, while FreeBSD made it trivial to override that and do what you needed to do with no further fuss.
  • yencabulator 4y ago
    Back in the day there was a patch floating around that let you mark mounts as "bad", and all open files would be shunted to a "badfs" which gave I/O errors for all operations. Most of the discussion around it has linkrotted. https://lwn.net/Articles/192632/ https://lwn.net/Articles/192632/ has some mentions. Some filesystems implement a less-comprehensive variant that's `umount(2)` with `MNT_FORCE` -- but generally that's only network/FUSE-style ones: MNT_FORCE (since Linux 2.1.116) Ask the filesystem to abort pending requests before attempting the unmount. This may allow the unmount to complete without waiting for an inaccessible server, but could cause data loss. If, after aborting requests, some processes still have active references to the filesystem, the unmount will still fail. As at Linux 4.12, MNT_FORCE is supported only on the following filesystems: 9p (since Linux 2.6.16), ceph (since Linux 2.6.34), cifs (since Linux 2.6.12), fuse (since Linux 2.6.16), lustre (since Linux 3.11), and NFS (since Linux 2.1.116).