Friday, July 21, 2017

#1 2017-06-29 11:16:25 am

JohnW
Member
Registered: 2016-11-21
Posts: 7

Droplet handling zip files differently from other files

Hello,

I have a droplet for zipping files that used to work on OS X 10.5 and 10.6, but is having trouble zipping zip files on 10.12.

If I run the following code as a droplet, it will return one list of all the files dropped as long as none of them are zip files, such as three PDFs. If there is a zip file in the mix, it returns two lists -- first a list of all the files EXCEPT the zip file, then it loops back and shows only the zip file.

Applescript:


on open files_
   display dialog files_ as string
end open

Is there some way to get the zip files included in the list of all files?


Filed under: zip, droplet

Offline

 

#2 2017-06-29 11:56:41 am

Yvan Koenig
Member
Registered: 2006-09-14
Posts: 3111

Re: Droplet handling zip files differently from other files

Are you sure that the fact that files are zipped is really the cause of this behavior ?
What you describe resemble to a feature already described :
when we drop files whose quarantine bit is set with files whose quarantine bit is clear, the system treat them separately.

Shane STANLEY gave a way to get rid of that.

Applescript:

(*
open+
Script posted by Shane STANLEY
in applescript-users@lists.apple.com
in the thread AppleScript Droplet seems to receive strange file list
on 2017/02/17

*)


use AppleScript version "2.4" -- Yosemite (10.10) or later
use framework "Foundation"
use scripting additions
property filesToOpen : {}

on open fileList
   set my filesToOpen to my filesToOpen & fileList
   -- cancel any pending performSelector: requests
   current application's NSObject's cancelPreviousPerformRequestsWithTarget:me
   -- handle files after a short delay in case further events are received
   tell me to performSelector:"doOpen" withObject:(missing value) afterDelay:0.5
end open

on doOpen()
   copy my filesToOpen to fileList
   set my filesToOpen to {} -- reset for next time
   
   set aRes to length of fileList
   display dialog aRes as string
   
   repeat with i in fileList
       set j to POSIX path of i
       display dialog j
   end repeat
   
   tell me to quit
end doOpen

on quit
   continue quit
end quit

Yvan KOENIG running Sierra 10.12.5 in French (VALLAURIS, France) jeudi 29 juin 2017 18:56:06

Offline

 

#3 2017-06-30 07:09:40 am

JohnW
Member
Registered: 2016-11-21
Posts: 7

Re: Droplet handling zip files differently from other files

Excellent! I don't think the quarantine bit is the issue since it happens with newly created zip files. However, this code did fix the issue. Thank you very much Yvan (and Shane).

Offline

 

#4 2017-06-30 10:06:38 am

Yvan Koenig
Member
Registered: 2006-09-14
Posts: 3111

Re: Droplet handling zip files differently from other files

I guess that the files recently zipped have quarantine bit cleared while the non-zipped ones have their quarantine bit set.

Thanks again to Shane STANLEY you may check that with the script below

Applescript:

use AppleScript version "2.4"
use framework "Foundation"
use scripting additions

on getQuarantineValue:POSIXPath
   set theURL to current application's class "NSURL"'s fileURLWithPath:POSIXPath
   set {theResult, theValue, theError} to theURL's getResourceValue:(reference) forKey:(current application's NSURLQuarantinePropertiesKey) |error|:(reference)
   if theResult as boolean is false then error (theError's localizedDescription() as text)
   if theValue is not missing value then set theValue to theValue as record
   return theValue
end getQuarantineValue:


set theFolder to choose folder

tell application id "com.apple.SystemEvents"
   set theItems to POSIX path of every disk item of theFolder whose visible is true
end tell


repeat with anItem in theItems
   set theValue to (its getQuarantineValue:anItem)
   log anItem
   log theValue
   log linefeed
end repeat

(*
(*/Users/??????????/Downloads/2013-03-17-TUAW_Waldie.zip*)

(*missing value*)
(*
*)

(*/Users/??????????/Downloads/2013-ICF-Myths-Benefits-11x17.pdf*)
(*LSQuarantineType:LSQuarantineTypeSandboxed, LSQuarantineAgentName:Preview, LSQuarantineIsOwnedByCurrentUser:true, LSQuarantineTimeStamp:date mardi 2 mai 2017 à 22:10:58*)
(*
*)

*)

For 2013-03-17-TUAW_Waldie.zip the bit is cleared.
For 2013-ICF-Myths-Benefits-11x17.pdf it is set.

It would have been better to pass this script in my first message.

Yvan KOENIG running Sierra 10.12.5 in French (VALLAURIS, France) vendredi 30 juin 2017 17:06:23

Offline

 

#5 2017-07-02 02:43:58 pm

Nigel Garvey
Moderator
From:: Warwickshire, England
Registered: 2002-11-20
Posts: 4334

Re: Droplet handling zip files differently from other files

Yvan Koenig wrote:

when we drop files whose quarantine bit is set with files whose quarantine bit is clear, the system treat them separately.

Shane STANLEY gave a way to get rid of that.


Well. Having spent a few hours trying to understand Shane's script and googling, xcoding, and experimenting to try and get it to work reliably, I've come up with these observations:

1. When Shane originally posted the droplet script on the AppleScript-Users list, he stipulated that it should be saved as a stay open application. This presumably ensures that it hangs around long enough to receive any second batch of items and only quits in response its own, scripted 'quit' command.

2. I was going to say that even then it doesn't handle large numbers of items well, because when I drop the entire contents of my Downloads folder onto it — 119 items, 79 of them with quarantine data and 40 without — it only reports receiving 83 items. However, I've now tried the same drop with an ordinary droplet, which just displays how many items it's received, and this displays 40 and 43 in succession. So there's something else going on in the drop itself which loses the other 36 items — at least on my 10.11.6 system.

Further analysis reveals that the 40 items are the non-quarantined ones, the 43 are all the quarantined .zip, .dmg, and .pkg files, and the missing 36 are all the other quarantined items in the folder. Dropping the 27 items on my Desktop onto the ordinary droplet, I was getting 4 (the quarantined items) and 23 (non-quarantined) in that order. After I dragged one of the quarantined .dmgs from Downloads onto the Desktop, the results changed to 23 (non-quarantined) and 1 (the .dmg). Since returning the .dmg to Downloads, I've been getting 23 and 4 — in that order.  hmm

3. The terms "quarantine" and "quarantine bit set" can give the wrong impression if you're an English speaker. In English, you're either quarantined or you're not. If you're quarantined, you may subsequently be OK'd and released. In Mac OS, as far as I can make out, an item on disk is either subject to Mac OS's quarantine system or it's not. If subject to the quarantine system, it may be OK'd for the current user, but it remains linked to the system. It's the existence or not of this link — rather than the item being isolated or OK'd locally — which seems to influence the droplet anomaly.

4. An application can, if so written, specify if and how files it saves are handled by the quarantine system, although the effects may not be apparent to the current user. Shane's other script above has so far turned up two quarantine types amongst my own files: "LSQuarantineTypeWebDownload" (applied by Safari during downloads) and "LSQuarantineTypeSandboxed" (screenshots credited to Preview). There may be more. On my machine, zips created from the Finder menu aren't quarantined, so it may be — as Yvan's surmised — that it's the other files in JohnW's drops which were quarantined by the applications which created them.


NG

Offline

 

#6 2017-07-02 11:14:29 pm

Shane Stanley
Member
From:: Australia
Registered: 2002-12-07
Posts: 5046

Re: Droplet handling zip files differently from other files

Nigel Garvey wrote:

1. When Shane originally posted the droplet script on the AppleScript-Users list, he stipulated that it should be saved as a stay open application. This presumably ensures that it hangs around long enough to receive any second batch of items and only quits in response its own, scripted 'quit' command.


Yes. It's a pretty standard way of coalescing events in Cocoa. Think things like resizing windows, which can send huge numbers of window-size-changed events -- the idea is to coalesce them at appropriate points. The only nit I'd pick is to say that it waits for as many batches as there are, provided any batch is called within the delay interval of the previous one. It's possible there could be more than two open events sent.

2. I was going to say that even then it doesn't handle large numbers of items well, because when I drop the entire contents of my Downloads folder onto it — 119 items, 79 of them with quarantine data and 40 without — it only reports receiving 83 items. However, I've now tried the same drop with an ordinary droplet, which just displays how many items it's received, and this displays 40 and 43 in succession. So there's something else going on in the drop itself which loses the other 36 items — at least on my 10.11.6 system.


One thing I should mention is that the delay is arbitrary. It didn't fail in my tests, and it had a little leeway to a value where it did fail. But I confess I didn't try such big batches of files -- because there's a trade-off, in that the delay is wasting time (x number of events), I assumed what I figured was the sort of number I'd expect in most real-world use. However, given that our totals match, that's probably not an issue here.

Further analysis reveals that the 40 items are the non-quarantined ones, the 43 are all the quarantined .zip, .dmg, and .pkg files, and the missing 36 are all the other quarantined items in the folder. Dropping the 27 items on my Desktop onto the ordinary droplet, I was getting 4 (the quarantined items) and 23 (non-quarantined) in that order. After I dragged one of the quarantined .dmgs from Downloads onto the Desktop, the results changed to 23 (non-quarantined) and 1 (the .dmg). Since returning the .dmg to Downloads, I've been getting 23 and 4 — in that order.  hmm


I'm letting that pass sad But if you know which are the 36 missed files, I'd be interested to know what happens if you drag only them (or some subset of them).

3. The terms "quarantine" and "quarantine bit set" can give the wrong impression if you're an English speaker. In English, you're either quarantined or you're not. If you're quarantined, you may subsequently be OK'd and released. In Mac OS, as far as I can make out, an item on disk is either subject to Mac OS's quarantine system or it's not. If subject to the quarantine system, it may be OK'd for the current user, but it remains linked to the system. It's the existence or not of this link — rather than the item being isolated or OK'd locally — which seems to influence the droplet anomaly.


A fair point. My feeling, though, is that quarantining could be seen to imply some kind of physical separation, which would be equally as confusing. Perhaps "marked as quarantined" would be better.

4. An application can, if so written, specify if and how files it saves are handled by the quarantine system, although the effects may not be apparent to the current user. Shane's other script above has so far turned up two quarantine types amongst my own files: "LSQuarantineTypeWebDownload" (applied by Safari during downloads) and "LSQuarantineTypeSandboxed" (screenshots credited to Preview). There may be more.

There are, defined in LSQuarantine.h. The constants are defined with a k, as in kLSQuarantineTypeEmailAttachment.

On my machine, zips created from the Finder menu aren't quarantined, so it may be — as Yvan's surmised — that it's the other files in JohnW's drops which were quarantined by the applications which created them.


Yep. There's no reason for the zipping of files to require quarantining -- it should generally only apply to items received from external sources (and that doesn't even include things like USB sticks).


Shane Stanley <sstanley@myriad-com.com.au>
www.macosxautomation.com/applescript/apps/

Offline

 

#7 2017-07-03 05:00:58 am

Nigel Garvey
Moderator
From:: Warwickshire, England
Registered: 2002-11-20
Posts: 4334

Re: Droplet handling zip files differently from other files

Hi Shane.

Thanks for your reply. I hope my convoluted description didn't give the impression I was critising your script. Since I found the reference that it was supposed to be stay-open, it's been behaving very solidly.

I did think at first that it was being overwhelmed by the number of items in my Downloads folder, but I changed my mind after tests with the "ordinary" droplet I mentioned, whose code is:

Applescript:

on open files_
   display dialog (count files_) as text
end open

When the entire contents of my Downloads folder are dropped onto this at once, it triggers once for the non-quarantined items and again for a particular subset of the quarantined items. It doesn't trigger a third time for the remaining quarantined items, which suggests that these may simply not be getting through, which in turn would mean there was nothing your script could do about them. (I used a variation of this ordinary droplet to write the names of the items in each triggering to separate TextWrangler documents and your other script to determine their quarantine status.)

Testing with the much smaller number of items on my Desktop, I found that the mere inclusion of one of my quarantined .dmg files in the drop was enough to exclude all the other quarantined items dropped with it. This is no doubt what happens with the Downloads folder items too, except that quarantined .zips, .pkgs, and .dmgs seem to get along.

Further tests this morning:
Select one quarantined .zip (downloaded by Safari), two quarantined .pngs (created thus as screenshots), and three non-quarantined .scpts. Drop all six onto the "ordinary" droplet. Effect: the droplet triggers twice, showing 1, then 3.

Deselect the .zip and try again. Effect: the droplet triggers twice, showing 2, then 3.

Select only the .zip and the three .scpts and try again.  Effect: the droplet triggers twice, showing 1, then 3.

Select only the .zip and the two .pngs and try again. Effect: nothing.

Try again to be sure. Effect: still nothing.

Add the three .scpts to the selection and try again. Effect: the droplet triggers four times, showing 1, then 1, then 1, then 2!  hmm

Last edited by Nigel Garvey (2017-07-03 05:03:50 am)


NG

Offline

 

#8 2017-07-03 06:57:14 am

Shane Stanley
Member
From:: Australia
Registered: 2002-12-07
Posts: 5046

Re: Droplet handling zip files differently from other files

Oy. I guess the order in which they're handled, which may or may not relate to selection order, is also a likely factor. And that last case is certainly interesting, with four events.

But in both cases the scripts seem to be catching everything sent to them, so I'm not there's much more can be done. It should probably be reported as a bug, but for the life of me, I don't see how...


Shane Stanley <sstanley@myriad-com.com.au>
www.macosxautomation.com/applescript/apps/

Offline

 

#9 2017-07-03 07:04:15 am

Yvan Koenig
Member
Registered: 2006-09-14
Posts: 3111

Re: Droplet handling zip files differently from other files

Oops, Nigel is right, I forgot that the script is supposed to be saved as a stay open application.

When I ran it some minutes ago I got a surprising behavior.
Two of the dropped items have quarantine bit set.
The first one : Firefox 54.0.1.dmg was listed with no problem
but the second : fmp_trial_fm_16.0.1.162.dmg forced the system to open a dialog saying "verifying fmp_trial_fm_16.0.1.162.dmg" (with a progress bar).

What may explain this difference ?

Yvan KOENIG running Sierra 10.12.5 in French (VALLAURIS, France) lundi 3 juillet 2017 14:04:09

Offline

 

#10 2017-07-03 07:09:00 am

Shane Stanley
Member
From:: Australia
Registered: 2002-12-07
Posts: 5046

Re: Droplet handling zip files differently from other files

Yvan Koenig wrote:

What may explain this difference ?


I suspect that's something peculiar to some .dmg files.


Shane Stanley <sstanley@myriad-com.com.au>
www.macosxautomation.com/applescript/apps/

Offline

 

#11 2017-07-13 06:18:32 pm

JohnW
Member
Registered: 2016-11-21
Posts: 7

Re: Droplet handling zip files differently from other files

On my machine, zips created from the Finder menu aren't quarantined, so it may be — as Yvan's surmised — that it's the other files in JohnW's drops which were quarantined by the applications which created them.



Hi Shane,

That makes perfect sense. Most of the files being dropped are downloaded via FTP. I guess I did not realize these files were quarantined because Finder does not give a warning when opening quarantined documents? I think it only does so for applications and disk images.

Offline

 

Board footer

Powered by FluxBB

RSS (new topics) RSS (active topics)