• Vera (unregistered)

    Cargo-cult programming with a cult of one, and a lack of informed oversight to stop this from happening. Not terribly surprising, and I hope ArSo stays in the mindset to question what Kurt is "teaching."

  • (nodebb)

    Ooooh, it can see how this could actually be a hard one. See, if you use Thread.Sleep in an async context you will have potential deadlocks. So you have to use async Task.Delay(). Now to be extra safe and to use a generic solution that works anyway, DateTime is a better choice.

    Mah, just kidding. Just use Thread.Sleep or Task.Delay.

  • Bogolese (unregistered)

    "Honestly, I think you should ask for more." and post the sample code here. It would be Brillant!

  • (nodebb)

    Why not give one of the CPU cores a brief high intensity workout in a pointless loop? Burning some calories will keep the fat away.

  • Simon (unregistered)

    As a Brit, I wouldn’t have chosen "ArSo" as a nickname

  • Jonathan (unregistered)

    The method of delaying is indeed a WTF.

    However, waiting a bit before trying to delete the file is possibly a very reasonable solution to file deletion being very often surprisingly unreliable on .NET.

  • The Incredible Holk (unregistered)

    Not a WTF. The requirement was "at least 1 second delay", and Kurt was aware of the wraparound issue. The second loop will run for 1 second.

    Leap seconds, on the other hand...

  • NotAThingThatHappens (unregistered)

    "This delay is at most one second"

    Well, maybe Kurt found out the the systems virus scanner would lock a file and needed a delay. Then Kurt found out that the the scan never took longer than a second. This cause the first loop.

    The in production sometimes the file was still locked because of the 0:00:999 edge case. And the second loop was added. So that the delay was always 'at least one second'.

    Its a perfectly simple solution that avoids high-tech kludges such as an additional variable and or math.

  • (nodebb) in reply to Mr. TA

    Or if it is one from Intel, burst into flames in a highly spectacular fashion? :-)

  • y2k16 (unregistered) in reply to MaxiTB

    But why wait at all? Why for 1-2 seconds? File.Copy has got to be blocking surely. So is there some other program (perhaps lying in wait using inotify or someth) that takes 1 second to react to the new file creation? What is going on here?

  • Tinkle (unregistered)

    Wow, what was wrong with File.Move?

    Were they scared because there is no File.Rename?

    I suspect this is code ported over from an older language - probably VB6.

    This WTF keeps on giving...

  • (nodebb) in reply to y2k16

    Anti-Virus Apps. It makes actually sometimes sense to wait after write operations to wait a bit before doing delete. So there is actually unironically a legit reason why you want to do this in some cases.

  • y2k16 (unregistered) in reply to MaxiTB

    I'm sorry you live in that ecosystem. Help is available

  • (nodebb) in reply to MaxiTB

    Anti-Virus Apps. It makes actually sometimes sense to wait after write operations to wait a bit before doing delete.

    If it makes sense (i.e. is actually necessary) to do that, then your AV application is defective.(1) It should run the check synchronously during the syscall that actually creates/modifies/tries-to-run etc. the file so that the file is always usable by applications without inducing weirdly bizarre behaviours (mostly unexpectable and inexplicable errors). Deletion is a syscall that doesn't need to do any AV analysis, but open-before-read (with or without write), close-after-write (with or without read), and execute do, and must not allow the operation to complete before the AV analysis is finished.

    I know whereof I speak because I used to work on the file-access interception component of an AV system back in the day.

    (1) I'm well aware that such a defect would be merely one of at least five(2) serious defects, but this one is second in importance behind actual crashy shit.

    (2) For large (or larger than that, probably) values of five...

  • (nodebb) in reply to Steve_The_Cynic

    Defective is a strong word, I just call it expected because observed behavior.

    In that case I experienced some issues, the AV solution shadow locked both source and destination file; so basically the delete did not fail, it just was prevented. That is actually pretty common AV behavior, it makes the software look like it doesn't have an effect on regular operations, but obviously it does. Even in a perfect system, you have latency, so there is a time delay between releasing a file handle and receiving notifications that it was closed. When you add the overhead of the AV software, well, you will always end up in a race condition.

    I had funny stuff happening before, like committing to git a change that had no chances but a different hash etc. AV are a pain in the butt, they are often very sloppy done, rarely effective and just eat up resources - but I had a ton of clients that ran them in DMZ on servers because - unreasonable policies, I guess?

  • Officer Johnny Holzkopf (unregistered) in reply to MaxiTB

    Sounds strange. Shouldn't the file operations be handled by the VFS layer which then reports back to the problem program - not depending on if the actual writes have been synced to mass storage? It's obvious that this is a multi-level operation (VFS, device drivers, actual devices), and even if you put in delays here or there on level "n", the next lower level "n-1" might report to have done something, but level "n-2" is currently performing the operation or maybe has it queued for execution in a manner that some scheduler decides about, for example, when system load is low or when a certain amount of similar operations have been queued? Virus apps making stange assumptions about this "turtles all the way down" stack and relying on "facts" that aren't... (Exception: Only real-time operating systems define a fixed or predictable time for specific operations, so that's the thing you can rely on; however, you need to do the "time measuring" for intended delays correctly.)

  • (nodebb) in reply to MaxiTB

    If it locks (or otherwise blocks changes to) the file(s) outside the duration of the syscall, it's defective, whether it's observed behaviour or not. I'm not going to entertain any discussion on this point.

    so basically the delete did not fail, it just was prevented

    Are you saying that the delete syscall reported success but the file was not deleted? What the ever-living fuck? That's definitely a defect.

  • (nodebb) in reply to Steve_The_Cynic

    Are you saying that the delete syscall reported success but the file was not deleted? What the ever-living fuck? That's definitely a defect.

    Yes, that's how it worked. Both AV solutions, I could reproduce this, queued write commands when they processed a file in that moment and then executed the command after the scan process (and potential quarantine) is completed. So basically they hook at Windows kernel level into common IO functions and return success values if no obvious errors were made. If queued commands cannot be executed when it's his turn, they failed silently.

    It's actually not that hard to test, you just have to stress test the AV by opening a lot of IO handles and do a lot of random access write operations (so seeking beyond the cache size, changing a byte, repeat) sensitive directories/file types. That will completely overload the AV engine and then those queue delays can rise up to seconds. Obviously you need to have live-checks on; I haven't seen this behavior with manual triggered scans.

    Addendum 2024-11-15 06:07: The delete issue happened with an AV solution starting with M and the git issue happened with an AV solution starting with K. I'm pretty sure you can guess what I'm talking about :-)

  • (nodebb)

    "Why is there a delay?" Large file, copying across a slow network?

  • y2k16 (unregistered) in reply to JanDoggen

    How could that cause a delay after the blocking file function call has already returned? (And if you're trying to manually create coherency across something like Google Drive or Nextcloud, as opposed to e.g. NFS, then that's an architecture WTF.)

  • Klimax (unregistered) in reply to MaxiTB

    M as a certain infamous person with Scottish-like name and K is similar to certain Russian chess master (and from same country)?

  • Loren Pechtel (unregistered)

    Inefficient but this is a workaround for AV issues. I've had far too many issues with AV royally messing with the system, some of which I've never found good answers for. Creating large amounts of data, especially if you're not writing it in a single operation can totally mess you up. I couldn't watch a video today because I had a 2gb file download running--Defender was hogging so much CPU power that the video wasn't behaving.

Leave a comment on “Secondary Waits”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article