• 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?

Leave a comment on “Secondary Waits”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article