Fixes hdiutil error #4104

When running make deploy, sometimes hdiutil errors: hdiutil: convert failed - Resource temporarily unavailable. The following patch pauses for five seconds and seems to fix the error.

Waiting doesn't seem to be a very robust solution when there is some system load. Isn't there another way to wait for hdiutil to be ready?

My best guess was that it hadn't finished mounting and needed to pause. If anyone can shine a better light on it, great.

On Apr 29, 2014, at 3:16 AM, "Wladimir J. van der Laan" notifications@github.com wrote:

Waiting doesn't seem to be a very robust solution when there is some system load. Isn't there another way to wait for hdiutil to be ready?

— Reply to this email directly or view it on GitHub.

@iangcarroll That seems like a reasonable guess, but what @laanwj means is that waiting some arbitrary amount of time is rarely a good solution - for someone else it may take longer. Isn't there a way to check whether the mounting has completed, and just wait until that is done?

Yes, to clarify, I'm not against waiting, but against waiting a fixed amount of time.

Even waiting a fixed amount of time would be OK if you can detect the specific error and repeat the operation in that case.

Automatic sanity-testing: FAILED BUILD/TEST, see http://jenkins.bluematt.me/pull-tester/p4104_68aa01e51fb9673ff2739825529a3fee36df79b4/ for binaries and test log.

This could happen for one of several reasons:

1. It chanages paths in makefile.linux-mingw or otherwise changes build scripts in a way that made them incompatible with the automated testing scripts (please tweak those patches in qa/pull-tester)
2. It adds/modifies tests which test network rules (thanks for doing that), which conflicts with a patch applied at test time
3. It does not build on either Linux i386 or Win32 (via MinGW cross compile)
4. The test suite fails on either Linux i386 or Win32
5. The block test-cases failed (lookup the first bNN identifier which failed in https://github.com/TheBlueMatt/test-scripts/blob/master/FullBlockTestGenerator.java)

If you believe this to be in error, please ping BlueMatt on freenode or TheBlueMatt here.

This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.

@theuni Have you ever encountered this problem?

I've never seen it, no.

The applescript should be sync, afaik. I'm not sure how it would return before the image is unmounted.

Though I agree that it's a bad fix, I'm not opposed to it if it actually fixes the problem. The net is littered with scripts to handle mounting/unmounting, and random waits seem to be commonplace.

I just don't know how to find out if it's ready or not. If anyone could shine some light related to this... I'll try reproducing later today.

On Jun 24, 2014, at 2:08 PM, Cory Fields notifications@github.com wrote:

I've never seen it, no.

The applescript should be sync, afaik. I'm not sure how it would return before the image is unmounted.

Though I agree that it's a bad fix, I'm not opposed to it if it actually fixes the problem. The net is littered with scripts to handle mounting/unmounting, and random waits seem to be commonplace.

— Reply to this email directly or view it on GitHub.

@iangcarroll About the only thing I can think of to try would be to remove the 'eject' from the applescript, and run 'hdiutil eject...' manually afterwards instead. At least that way you could debug the timing somewhat. For me, 'hdiutil eject /mount/point' seems to return pretty much instantly, and presumably it's actually ejected before exiting.

Data point: https://chromium.googlesource.com/external/dart/bleeding_edge/+/refs/heads/master/dart/tools/mac_build_editor_dmg.sh

Google adds in a wait as well. I suspect that under whatever circumstances that trigger the race, there's probably not a way to detect hdiutil's finish.

How about we just borrow google's solution?

# Wait until the script above has umounted the image
while [ -e "$VOLUME_MOUNTPOINT" ]; do
echo "Waiting for Finder to eject $VOLUME_MOUNTPOINT"
sleep 2
done

(adjust variable name as necessary ofc)

One more example solution: https://chromium.googlesource.com/webm/webmquicktime/+/ed0b174b6e6d7b4c947cdd5a364d4cd43f40ec35/third_party/yoursway-create-dmg/support/template.applescript

The loop for existence of the mount point is acceptable. At least it detects that the operation was finished instead of adding an arbitrary wait which still may not be enough under heavy system loads.

@iangcarroll Are you going to update this?

Yeah, I'll do it when I get back to my house on Monday.

Sent from my iPhone

On Jul 4, 2014, at 3:24 AM, Wladimir J. van der Laan notifications@github.com wrote:

@iangcarroll Are you going to update this?

— Reply to this email directly or view it on GitHub.

@iangcarroll ping

Just going to merge this as-is, having a solution is better than no solution at all.