I often drag images from my browser to the Download folder on my Dock. I decided to write an Apple Script that kicks in when the file is copied, displaying a dialog so I can rename the file. Thanks to these forums I figured that part out, and it renames the file just fine.
However, after I copy a picture it takes a really long time (average of 9 seconds!!) before I see the dialog box. I’d like to be able to rename the file right away, instead of waiting every single time I save an image. Saving in a image doesn’t take more than a fraction of a second, so I don’t get why it takes so long for this Folder Action to start.
Here’s what I’m using:
on adding folder items to thisFolder after receiving droppedFiles
set counter to 1
if counter is equal to 1 then
repeat with droppedFile in droppedFiles
try
-- current filename
set CurrentName to name of (info for droppedFile)
-- display dialog and store result
set NewName to text returned of (display dialog "Enter new filename:" default answer CurrentName buttons {"Cancel", "OK"} default button 2)
-- replace spaces with dashes
set NewName to do shell script "echo " & NewName & " | perl -pe 's/ /-/g'"
-- everything to lowercase
set NewName to do shell script "echo " & NewName & " | tr '[:upper:]' '[:lower:]' "
-- add current extension
set NewName to NewName & "." & name extension of (info for droppedFile)
-- rename the file
tell application "Finder" to set name of droppedFile to NewName
end try
set counter to counter + 1
end repeat
end if
end adding folder items to
Is there a way to make this work instantly?
Model: MacBook C2D 2.0GHz
Browser: Safari 533.4
Operating System: Mac OS X (10.6)
It is filed as a bug. 9 seconds are still very long? I might wait upto 5 secons but I’m on 3GHz with SSD.
I don’t know exactly why, but it seems like they are giving the gui and unfair amount of “juice”.
But: have you read your console file. Does your console file revealy many conflicts like DYLD conflicts and so on?
I might help (but I can not guarantee it) to have a system in total shape and measuring the times then.
Not as a folder action. There are two things that cause the slowdown:
Checking a folder takes time/cycles, so it’s probably only done once every few seconds; doing it to often is going to slow other things down.
Once a file is found, it has to check that it’s been fully written, and there’s no standard OS-level way to do that, so it basically checks to see if its file size has changed every few seconds. Obviously that gap has to be meaningful or it will make a mistake.
But why use folder actions at all for such a thing? Why not just have a script that produces the dialog and moves the file?
I need the same functionality that you, but for another purpose. I want to rename the files produced by CUPS-pdf before
I forget what they was all about.
The thing would be for me to create a script that starts up a dialog for every file in the folder. (Hopefully there is only one document there). It should be invoked by a shortcut key, rename the file and move it to some other directory.
In your case, you might want to try to write a droplet to drop the files upon. So that you don’t extend your workflow.
I’m not sure if it would work but it would be interesting to check it out.
If the droplet then moved the files to the correct folder afterwards, you would have achieved the same as you would do if your current solution worked. - Just a thought.
I thought about making that droplet, and I did, because I have had the same problem.
I was also interested to know whether that was a good alternative to a folder action. My conclusion so far is that a droplet will do.
-At least if you put in your dock.
The droplet drops the pictures to the desktop, then shows up a dialog and asks for a new name.
on open theFileAliases
local new_name, theFile
repeat with aFileAlias in theFileAliases
tell me
set new_name to text returned of (display dialog "Input a new new name for the file " default answer (extract_filename_from(aFileAlias as text) as text)) as text
end tell
tell application "Finder"
set theFile to (a reference to file (aFileAlias as text))
try
move theFile to folder (path to desktop as text) without replacing
on error e number n
display dialog "" & e & n
end try
try
set theFile to (a reference to file aFileAlias as text)
set name of item theFile to new_name
on error e number n
display dialog "" & e & n & "Here"
display alert "Something went wrong during renaming of " & (aFileAlias as text) & ". Exits.. " as warning
error number -128
end try
end tell
end repeat
end open
on extract_filename_from(the_filepath)
set the_filepath to the_filepath as text
set x to the offset of ":" in (the reverse of every character of the_filepath) as string
return ((characters -(x - 1) thru -1 of the_filepath) as text)
end extract_filename_from
Should anyone find this useful but needs to specify a different path to the folder to which to save the images, then
I suggest you use the script here.
All coercions (but one) in your script are useless.
For this purpose the Finder treats file references and aliases in the same way.
It’s not necessary to coerce an alias to text an then to file reference.
This does the same
on open theFileAliases
repeat with aFileAlias in theFileAliases
tell me
set new_name to text returned of (display dialog "Input a new new name for the file " default answer (name of (info for aFileAlias)))
end tell
tell application "Finder"
try
-- the result of move is a reference to the file at the new location
set movedFile to move aFileAlias to desktop without replacing
try
set name of movedFile to new_name -- as Unicode text
on error e number n
display dialog "" & e & n & "Here"
display alert "Something went wrong during renaming of " & (aFileAlias as text) & ". Exits.. " as warning
error number -128
end try
on error e number n
display dialog "" & e & n
end try
end tell
end repeat
end open
It is far more elegant the way you have done it. I forgot that Finder coerces by itself.
And you use the returned value of move as well. I didn’t dare do that when I wrote it.
And I see you use nested try blocks as well. I didn’t dare do that neither.
As a matter of fact I didn’t think it worked anymore. But it might have been something else that was wrong
when I drew that conclusion.
The speed of my launchd items is nowhere near the speed of the launching in the video.
I experience the launchd items to be pretty slow as well. Today day i read a security note from intego about some widely spread spyware on Mac Os X and wonders if that is the case of my slow folder actions and bad watchpaths performance. The spyware is at least reinstalled via launchd, but the security note from intego states that it hogs up system resources, and that would of course affect over all launchd and folder actions performance.
I’ll personally investigate that by installing Little Snitch and see what it finds.
Well I didn’t find anything unusual when using little Snitch, at least not anything that I could spot.
Just my named daemon, which is my private caching name server to speed up browsing.
Pondering investing 90 euro in the intego software. -That is a rather stiff price for buying anti spy software.
-But I got antivirus as well. Apple do recommend using two kinds of anti virus software nowadays so I’ll guess I’ll
install clamXav from macports.org as well.
As a matter of fact I did invest 90 and will come back with an update.
Well this is might be the way things gets when big companys like Google starts banning Windows as an operating system on their pc’s