I suspect the behaviour has more to do with resource forks
And for that reason ditto is probably a better choice than unzip.
You're absolutely right, Shane. I had a brief look at ditto last
night - but it was late, and the ol' brainbox was way too pickled to
do anything remotely useful. Since ditto preserves resource forks and
HFS meta-data, it seems to improve several aspects of extraction. :-)
So let's try that again:
------------------------
to extract_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 "ditto -x -k " & p & space & 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 extract_and_delete
extract_and_delete(choose file of type "com.pkware.zip-archive"
without invisibles)
------------------------
(For a pre-Tiger OS, the '-rsrc' option should be included.)
