opening multiple archives using MacVim causes dialog box explosion

[GoogleCodeExporter]

This is 3.6 on Mountain Lion, using Snapshot 66 of MacVim.  MacVim hasn't 
changed in about a month, and TheUnarchiver is the only change.

Put multiple archives in one directory, like foo/a.xz and foo/b.xz.   Open 
MacVim and do ":cd foo".  Then do ":!open a.xz b.xz".  (Both of these commands 
in MacVim).

Expected behavior: Prior to 3.6, TheUnarchiver would simply open those archives 
without any dialog box whatsoever (I have it set to "Extract folder to same 
folder as archive").

Observed behavior: After 3.6, TheUnarchiver gives one dialog box per archive 
asking me where I want to save the unpacked things.

Note that neither archive has multiple top-level elements; they should just 
expand to directories a and b with no prompting.

Note also that that "open a.xz b.xz" command (which is what MacVim is calling 
via a shell) works without the strange behavior if called straight from 
Terminal, or if called inside the Terminal version of vim. 

Note also that the strange behavior doesn't happen if I only open *one* archive 
at a time, even from MacVim.

Something has changed in TheUnarc. that's causing this.

Original issue reported on code.google.com by chd...@gmail.com on 7 Jan 2013 at 8:02

[GoogleCodeExporter]

Is it definitely destination dialogs, and not dialogs asking for sandbox access?

Original comment by paracel...@gmail.com on 7 Jan 2013 at 8:08

[GoogleCodeExporter]

The dialog says nothing about sandboxing, but shows the same filesystem 
selection that destination dialogs do.  At the bottom right there is a button 
that says "Extract".

It just occurred to me that I've been running Legacy 3.6.  However, I've 
*always* been using Legacy on Mountain Lion and it's never done this before.   
I'll try non-Legacy right now, and later will try Legacy on 10.5 to see if I 
get the same thing.

Original comment by chd...@gmail.com on 7 Jan 2013 at 10:06

[GoogleCodeExporter]

Same thing here even on non-Legacy.  Later I'll be able to try 10.5.8 and also 
10.7.5.

Original comment by chd...@gmail.com on 7 Jan 2013 at 10:09

[GoogleCodeExporter]

Perhaps it is somehow not getting access to the user defaults when launched 
from inside MacVim? Try changing some other settings and see they still apply 
when launching from inside MacVim.

Original comment by paracel...@gmail.com on 7 Jan 2013 at 10:13

[GoogleCodeExporter]

OK, I just built from source on Mountain Lion.  The resulting build did not 
exhibit the weird behavior.  Then I tried replacing it with 3.6 non-legacy 
downloaded from your site, and the odd behavior returned---except that now the 
dialog *is* saying something about sandboxing, and it's giving me that dialog 
even if I only open one archive.

In my build from source I comment out the lines of the xcodeproj file that talk 
about signing, because otherwise it won't build since I'm not you.  So that 
would explain why the home-built doesn't have the weird behavior.

But two odd things: (1) I have the sandboxing stuff turned off in System 
Preferences-->Security-->General-->Allow applications downloaded from Anywhere. 
 (2) Why would the Legacy version be popping up those dialogs where it didn't 
prior to 3.6?

Original comment by chd...@gmail.com on 7 Jan 2013 at 10:18

[GoogleCodeExporter]

I changed the default extraction location from "same as the archive" to 
"~/desktop", then tried the usual deal from inside MacVim.  I get, on Legacy 
version, the same odd behavior.  And even though the default location is 
desktop now, the dialogs open on ~/Documents.  I wonder if these are sandbox 
dialogs which are (a) for some reason being triggered on Legacy, and (b) when 
they are triggered lack the text describing what the dialog is asking for.

Original comment by chd...@gmail.com on 7 Jan 2013 at 10:26

[GoogleCodeExporter]

Aaargh.  Now I'm getting the odd behavior even on the one I built from source.  
I've even totally trashed the prefs twice.

I notice that when I go to trash them, there is a second pref file in there 
like this: cx.c3.theunarchiver.plist.Mu2xpfH, with a weird suffix.

Original comment by chd...@gmail.com on 7 Jan 2013 at 10:30

[GoogleCodeExporter]

That weird pref file has the odd permissions -rw------

Original comment by chd...@gmail.com on 7 Jan 2013 at 10:31

[GoogleCodeExporter]

Sheesh, I get it, it's a tempfile.

Original comment by chd...@gmail.com on 7 Jan 2013 at 10:33

[GoogleCodeExporter]

I can now confirm the strangeness on a second machine running Mountain Lion.

Original comment by chd...@gmail.com on 8 Jan 2013 at 4:21

[GoogleCodeExporter]

I can now confirm the strangeness on 10.7.5.  And what's *really* weird is that 
I can also confirm it on 10.5.8 PPC.  That surely means the dialogs are not 
sandbox dialogs, but destination dialogs, right?  Also, if I click "extract" on 
one of those dialogs (Lion or greater), it isn't "remembered" for the next time 
as a real sandbox dialog would do.

Also, I've confirmed that this oddness goes back at least to v3.4.

Also, I've confirmed that on all tested versions and OS's, the oddness is 
intermittent.  By that I mean that about 1 out of every 5 attempts to open two 
archives at once in the described manner from inside MacVim will *succeed* 
without throwing the dialogs.  I can find no pattern so far.

So to sum up to far:

** The dialog explosion happens on 10.8.2 with Legacy and NonLegacy, from 3.4 
and up.  It happens on 10.7.5 Legacy and NonLegacy from 3.4 and up.  It happens 
on 10.5.8 with Legacy from 3.4 and up.  On all three OSX versions, it happens 
on versions of TheUnarch. that I built from source on that very machine.

** The dialogs seem to be destination dialogs.

** The dialog explosion occurs about 4 out of every 5 attempts.  And on about 1 
out of every 10 attempts or so, I get a dialog on only one of the two archives, 
while the other one extracts normally.

** And a new observation: If instead of ":!open a.xz b.xz" in MacVim, I do 
":call system('open a.xz b.xz')", then nothing at all happens.  TheUnarch 
doesn't open at all (not even if I only try to open a single archive a.xz that 
way).  This is weird because this way of calling it ought to be equivalent, and 
also because if I try to open a folders or plain text files instead of 
archives, they open just fine with their respective programs.  And if I try to 
open two different archives a.zip and b.zip, where I have zip files set to open 
not with TheUnarch but rather with ArchiveUtility, they open just fine.  So 
this is definitely specific to TheUnarch; it is somehow not interacting 
properly with the 'open' shell command in all contexts.  All other apps for all 
kinds of files (not just archives) will respond to ":call system('open blah')". 
 Perhaps whatever it is about TheUnarch that causes it not to respond to ":call 
system()" is also causing it to have dialog explosions in response to "!open".

Original comment by chd...@gmail.com on 8 Jan 2013 at 3:28

[GoogleCodeExporter]

I wonder if it is related to the other mysterious problem where certain apps 
that hook into all other programs cause the opening of archives to fail 
entirely. I understand that has something to do with timing, and also happens 
before any The Unarchiver code is called at all.

Generally, Launch Services is terribly buggy, so I'd be tempted to blame it, 
but if you can find a version that doesn't have problems, that might help in 
tracking down what it is that triggers the bug, wherever it is.

Original comment by paracel...@gmail.com on 8 Jan 2013 at 4:22

[GoogleCodeExporter]

Wow...I've now confirmed the dialog explosion occurs all the way back to 
TheUnarc version 1.6!!!  (On Mountain Lion).  I trashed my prefs each time I 
moved one version of TheUnarc backwards.

Original comment by chd...@gmail.com on 8 Jan 2013 at 7:29

[GoogleCodeExporter]

Wow...I've now confirmed the dialog explosion occurs all the way back to 
TheUnarc version 1.6!!!  (On Mountain Lion).  I trashed my prefs each time I 
moved one version of TheUnarc backwards.

Original comment by chd...@gmail.com on 8 Jan 2013 at 7:29

[GoogleCodeExporter]

Maybe you should start checking if some other program you installed is actually 
causing this?

Original comment by paracel...@gmail.com on 8 Jan 2013 at 7:33

[GoogleCodeExporter]

Was this ever resolved?

Original comment by paracel...@gmail.com on 30 Oct 2014 at 9:11

[GoogleCodeExporter]

No, it was never resolved.  I continued to see it all through Mavericks.  
Haven't yet had a chance to test on Yosemite.

Original comment by chd...@gmail.com on 31 Oct 2014 at 1:09