Your script has an interesting side effect , Kai, if the zipped
"file" is a folder containing folders. The original folder is, of
course, restored as expected, but a new folder is created with it
called: "__MACOSX" (two leading underscores) containing the now
empty folders of the original but none of the files.
That is interesting, Adam. Since I can't replicate the behaviour
with any of my current files (which contain multiple folders), I'm
wondering if there's another possible cause. If you wouldn't mind
sending me a copy of an offending zip file, I'd be happy to dig
around...
Thanks for the files that you kindly sent, Adam - very helpful.
I see what you mean - although I suspect the behaviour has more to do
with resource forks, and the way files are copied/zipped, than with
the number of folders involved. Since all the files in the primary
unzipped folder(s) seem to be intact, this appears to fix the issue
here:
----------------------
(* Caution: the last statement in the try block deletes the zip file
without trashing it *)
to unzip_and_delete(z)
try
set p to quoted form of z's POSIX path
set n to paragraph 2 of (do shell script "zipinfo " & p)
set n to n's text ((offset of ":" in n) + 4) thru -(1 + ((n ends
with "/") as integer))
set d to (do shell script "dirname " & p) & "/"
set f to d & n as POSIX file
tell application "Finder" to if f exists then error "The " & item
f's class & " \"" & n & "\" already exists."
do shell script "unzip -q " & p & " -x __MACOSX/* -d " & quoted
form of d
do shell script "rm " & p (* delete the zip file without trashing *)
on error e
display dialog e buttons {"Cancel"} default button 1
end try
end unzip_and_delete
unzip_and_delete(choose file of type "com.pkware.zip-archive" without
invisibles)
