Good catch, Kel; I’ve had that happen to me, but forgot to warn of it.
Funny you should mention that, I just got to the point in my script to notice that. When I rename a file, it gets picked-up and re-checked in my repeat loop.
So when I have a file ABC.pdf and my script detects an extension error and fixes it to ABC.ai, the script then puts ABC.ai through the scan as if it were a new file. Doesn’t hurt anything, but it’s inefficient. Later when I want to fix Photoshop files, this will become a big problem.
This is what I was hinting at earlier…if I rename a file, is there a way to “fix the alias list” so a given file isn’t re-sent through the loop because of a name change?
(I am in a position to post the code now, if anyone wants…but it’s just over 500 lines long–I use lots of comments. It can currently detect and repair Illustrator files, PDF files, and rename improper extensions for Illustrator and PDF files. And I haven’t given it the once-over for ways to do things better. Eventually it will do most common graphics formats.)
Suppose you had a list of alias references. You can rename item n of the list and update the reference like this:
set this_ref to item n of l
set name of this_ref to “NewName”
set item n of l to (this_ref as string) as alias
Another good way is to just keep a list of paths as text especially if you have a lot of items.
gl,
Okay suddenly my script has a poltergeist…
Every time I run the script now it’s “remembering” the last items I dropped on it and adding the new drop to it. In other words, “g_dropped_items” does not seem to be clearing between runs. Yet if I wait a few minutes, it will “reset” on it’s own. :-/
So if you drop a single file, it processes the first time correctly. Drop another single file, and it processes the previous one and the new one. Drop another, and it processes the previous two plus the new one, etc. You can check the log file it outputs
All I can think of is I made some subtle mis-type and activated some wierd feature or technique. Or I’ve been staring at this script too long…
--
-- debugging on?
property g_debug : true
--basic file path and names
property g_home_folder_path : path to home folder
property g_log_file_name : "File Repair Log.txt"
property g_dropped_items : {} --the items dropped on the "on open" handler
on logMe(log_string, indent_level)
if g_debug is true then --allows turning the debugger on and off so my logMe's can be left in final version
set log_target to (g_home_folder_path & "Library:Logs:" & g_log_file_name) as text
try
set log_file_ref to open for access file log_target with write permission
repeat indent_level times
write tab to log_file_ref starting at eof
end repeat
write ((log_string as text) & return) to log_file_ref starting at eof
close access log_file_ref
return true
on error
try
close access file log_target
end try
return false
end try
end if
end logMe
on open actionItems
my logMe("actionItems: " & actionItems & return, 0)
set cfr_version to "test" --remove when back in FaceSpan
repeat with current_actionItem in actionItems
tell application "Finder"
if (contents of current_actionItem as string) ends with ":" then
try
set g_dropped_items to g_dropped_items & (files of (entire contents of current_actionItem) as alias list)
on error -- only one file inside (works around bug)
set g_dropped_items to g_dropped_items & (files of (entire contents of current_actionItem) as alias as list)
end try
else
set g_dropped_items to g_dropped_items & current_actionItem
end if
end tell
end repeat
my logMe("g_dropped_items: " & g_dropped_items & return, 0)
quit
end open
Then someone want to explain why everything ran fine for 6 hours this morning then suddenly started acting wonky. Totally not fair. ;p
I usually use global variables, but have been following the lead of folks here who seem to use properties instead of globals. I asked in these forums once what the difference was…and got silence. Now I at least known one pitfall. 
Thanks Bruce!
It’s getting late, and this wierdness is getting worse…LOL…
Now that I’ve switched the list of aliases from a property to a local variable, renaming files no longer causes them to end-up being re-processed. Go figure…shrug
T.G.I.F…
Kevin; My bad :rolleyes: ;
When I’m debugging a droplet, I use properties so (at least in Script Debugger 4 which shows their values when the script is opened in it again) when I reopen the droplet script, I can see what the droplet “got”. I forgot to take that one out. Simply use “set theDropped to {}” after the open and before the repeat in my script or any evolution you have used.
In AppleScript properties are a) global and b) persistent from run to run in Tiger. I was using that persistence to see what happened. globals are effective everywhere in the script, but not persistent. Locals are persistent in the portion of the script they reside in, but nowhere else. They are most often used in handlers to indicate that a variable used somewhere else that might be global or a property doesn’t apply there.
My sample should have been:
on open theDrops
set theDropped to {}
repeat with D in theDrops
tell application "Finder"
if (contents of D as string) ends with ":" then
try
set theDropped to theDropped & (files of (entire contents of D) as alias list)
on error -- only one file inside
set theDropped to theDropped & (files of (entire contents of D) as alias as list)
end try
else
set theDropped to theDropped & D
end if
end tell
end repeat
end open
I didn’t test it to see what happens if you drop more while it’s processing the first batch.