The macosxhints Forums - To Applescript, Shell command or Automater?

The macosxhints Forums (http://hintsforums.macworld.com/index.php)

- OS X Developer (http://hintsforums.macworld.com/forumdisplay.php?f=27)

- - To Applescript, Shell command or Automater? (http://hintsforums.macworld.com/showthread.php?t=78979)

To Applescript, Shell command or Automater?

Hi,

I'm looking for some advice and (possible) help to implement some type of automated workflow of a set of directories.

Essentially, I need some way of taking a directory of any size and running it through a workflow that automatically creates multiple directories based on a maximum size (i.e. 4gb for DVD media) that are incrementally named.

For example I have a folder called "Work" that contains 40gb worth of other directories. The workflow then creates 10 Directories named "Archive 1, Archive 2 and so on..." and moves the files around so each Archive directory holds around 4gb

*Can you guess what I'm trying to do ;)

I would appreciate any help or advice if this would be better being an Applescript, Shell Command, or an Automater workflow. Also being really cheeky if anyone can give me a starter for 10 that would be magic.

Thanks in advance for any help.

Have you heard of Time Machine? It will be part of Leopard. Maybe you should wait a few weeks and use that. ;)

Ah, yes that would be lovely - unfortunately it all has to go back to PC based server, so I'll need an independent workflow rather than something built into the OS. But thanks for the reply.

this is fairly easy to do in applescript, though I'm guessing (perhaps erroneously) that there are other constraints (such as you'd prefer to keep files with similar dates together, or files with similar names, or you'd like to waste as little space as possible on the DVDs). these other constraints can complicate things immensely. but the basic script looks like this:

Code:

tell application "Finder"

        set burnFolderContainer to make new folder at desktop with properties {name:"Burn Baby Burn"}

        set theItems to every item of folder "path to folder to be copied"

        set Gb to 1.073741824E+9

        -- I used the precise number for a Gb; you might want to round it to 1000000000

        set sizeCap to 4 * Gb

        set i to 1

        set j to 1

        -- the '600 times' here and below is just to avoid endless loops if something goes awry.  

        -- if for some reason you need to make more then 600 burn folders, you scare me.  :)

        repeat 600 times

                set burnFolder to make new folder at burnFolderContainer with properties {name:("Burn Me " & i & ".fpbf")}

                set extension hidden of burnFolder to true

                set cumulativeSize to 0

                repeat 600 times

                        if j is greater than (count of theItems) then

                                beep

                                return

                        end if

                        set fileSize to physical size of (item j of theItems)

                        if fileSize is greater than sizeCap then

                                display alert "File " & (name of item j of theItems) & " skipped because it is larger than the disc size cap."

                                set j to j + 1

                        else if fileSize + cumulativeSize is less than sizeCap then

                                make new alias at burnFolder to item j of theItems

                                set j to j + 1

                                set cumulativeSize to cumulativeSize + fileSize

                        else

                                exit repeat

                        end if

                end repeat

                set i to i + 1

        end repeat

end tell

this goes through the folder item by item, putting aliases for the subfolders in a burn folder until maximum size is reached, and then making a new burn folder and starting over. you can then just open the burn folders and burn them to disk, and discard them afterwards.

I don't suppose it would be too hard to turn it into an automator workflow, if that's what you wanted...

zip and tar both claim to support "spanning" to break an archive into multiple members. That might be simpler for you, and save on disks as well.

well, for that matter, I seem to remember that Toast will automatically split things into multiple disks (if you're burning as HFS+). the only issue I would have with a segmented zip or hqx, though, is that you're in trouble if one of the disks gets scratched or lost.

wow, thank you to everyone for all their help! Very much appreciated.

TW, sorry to be a pain, I'm more used to a CLI - how does one specify the "path to directory" in Applesript? I've tried /Users/Username/Desktop to no avail. (And of course, a huge thank you for writing the script!)

well, in applescript you use the colon notation rather than the slash notation. so, to reference a folder on the desktop, the path would be:

Code:

HD:Users:Username:Desktop:Folder Name

you can also use either of the following, for portability:

Code:

-- use this only outside of a Finder tell block

set theThing to (path to desktop as text) & "Folder Name"



--inside a Finder tell, you have desktop as a special term, so...

tell application "Finder"

     set theThing to (desktop as text) & "Folder Name"

end tell

to make the text string into a file reference:

Code:

-- outside a Finder tell

set theThing to alias "HD:Users:Username:Desktop:Folder Name"



--inside a Finder tell

set theThing to file "HD:Users:Username:Desktop:Folder Name:Some File"

set theThing to folder "HD:Users:Username:Desktop:Folder Name"

I am trying to use this rather nice "splitter-upper" script on a very large folder stored on a mounted volume that is not the root volume. It fails because it says the fileSize is missing value. I remember something about the Finder being reluctant to compute size on other volumes, but not how to cure that.

Quote:

Originally Posted by NovaScotian (Post 413535)

well, there shouldn't be a problem using this script on a non-root volume (unless the volume is not hfs...). Unfortunately, I don't have my secondary drive with me at the moment, so I can't test it. I have noticed that the Finder is lazy about creating physical sizes. for instance, if I pick a random folder and and run this scriptlet a few times:

Code:

get physical size of every item of folder "--random--"

the first couple of times the list will be filled with missing values, and then suddenly all the correct values are there. that might solve your problem straight out.

you could also hack the file size up out of unix, at need:

Code:

set fileSize to physical size of (item j of theItems)

if fileSize is missing value then 

        set filePath to quoted form of (POSIX path of ((item j of theItems) as text))

        set fileSize to (do shell script "du -sk " & filePath & " | awk '{print $1}' -") * 1024

end if

that should give the same file size, though I'm suspicious about its accuracy if it hits an alias or an old-style dual fork file.

Quote:

Originally Posted by tw (Post 413569)

...I pick a random folder and and run this scriptlet a few times:

Code:

get physical size of every item of folder "--random--"

the first couple of times the list will be filled with missing values, and then suddenly all the correct values are there. that might solve your problem straight out.

Thanks tw: I think the quote above is the clue -- run a little loop asking for the physical size that continues (with a short delay) while PS is 'missing value' and then continues. Alternatively, put the phys size in an try block, and just try again. I'll try those on for size (sorry about that).

Sorry to be a pain, just got back to this tonight and tried to run the script as a test. An alert box pops up saying "AppleScript Error: Can't make missing value into type number."

With the value "cumulativeSize" highlighted on the line:

"else if fileSize + cumulativeSize is less than sizeCap then"

Sorry to be such a newbie.

sorry, my bad - seems some of the folders had bad permissions/errors. All fixed now and working a bloody treat! Thank You!

Quote:

Originally Posted by 1981 (Post 413876)

sorry, my bad - seems some of the folders had bad permissions/errors. All fixed now and working a bloody treat! Thank You!

ah, yeah, this is something NovaScotian discovered earlier. seems the Finder is a bit slow in calculating sizes for items. for future attempts, you might want to add this bit of code at the beginning of the Finder tell block (right after the tell application "Finder" line):

Code:

set splitThisFolder to folder "path to folder to be copied"

repeat 120 times

        set dummyVar to physical size of every item of splitThisFolder

        if dummyVar does not contain missing value then exit repeat

        delay 1

end repeat

basically this bit waits patiently while the Finder calculates all the item sizes in that folder before letting you move on to the rest of the script