Re: New Problem with recursion and timing and the finder updates
Re: New Problem with recursion and timing and the finder updates
- Subject: Re: New Problem with recursion and timing and the finder updates
- From: Andrew Oliver <email@hidden>
- Date: Tue, 18 Feb 2003 16:55:06 -0800
My first thought is to not use the Finder at all.
Under Mac OS X, I tend to think of the Finder as a simple portal to see
what's on the disk, leaving raw file manipulation to shell scripts, so
instead of:
tell application "Finder"
set name of some_file to new_filename
end tell
I would
do shell script "mv " & some_file & " " & new_filename
In this manner you're not dependent on how long it takes the Finder to
update its views to reflect the change. You don't even need the Finder
running.
Andrew
:)
On 2/18/03 4:07 PM, "Marc S.A. Glasgow" <email@hidden> wrote:
>
I've been working on a rewrite of RecursiveRenamer (revision for OS X),
>
an old utility of mine that runs through nested folders and renames the
>
files therein by the folder name & index count (i.e. - folder named
>
"bob" filled with miscellaneously named jpgs becomes filled with Bob
>
1.jpg, Bob 2.jpg, etc). The modifications for OS X have been minor,
>
since the original code was quite robust (such as adding 'without
>
invisibles' to list folder commands), but I've run into a couple
>
problems with recursion multithreading, timing and finder updating, to
>
wit:
>
>
1. Finder Name updating. The code renames all files within a folder to
>
a temporary name (randomly generated string) before renaming them to
>
the final name. This is done to ensure that there will be no naming
>
conflicts during the final renaming process (since in our example Bob
>
2.jpg may already exist). The problem is that the finder's filing
>
system seems to take it's merry old time about actually updating it's
>
state memory of what the current filenames are, and even with a
>
mandatory update at each instance of file renaming (accomplished with
>
Jon's commands -- thanks Jon!):
>
>
Tell app "Finder"
>
update NewPathFileName with necessity
>
end tell
>
>
It often starts to fail this around 85+ files into the process, as if
>
overwhelmed, especially if the call is occurring multiple times
>
concurrently because of spawning recursions. If I don't call the update
>
with necessity, then it doesn't update in a reliable manner at all
>
under 10.2.x. So the question is, is there a way to ensure that either
>
(a) Finder gets enough time to update the files, or better, (b) that a
>
spawned recursion process completes before returning to the prior
>
instance, or even better yet (c) is there a way to force the finder to
>
update all of the files in a nested hierarchy or disk at a single time
>
after all the renaming is complete?
>
>
2. How do I force the initial handler instant to end on an error
>
situation that's in a segment of a spawned recursion? Different actions
>
within the handler are now surrounded by try/on error/end try (which is
>
how I tracked down the issue to begin with), and often it is a multiply
>
spawned recursion that generates the error within it's code, so
>
canceling it doesn't stop the prior instant, which can still be
>
chugging away at files in vain.
>
>
Any insight helpful. I'd post the entirety of the code, but it's
>
exceptionally long and can be tedious to follow even with the comments
>
in place.
>
>
=-= Marc Glasgow
>
_______________________________________________
>
applescript-users mailing list | email@hidden
>
Help/Unsubscribe/Archives:
>
http://www.lists.apple.com/mailman/listinfo/applescript-users
>
Do not post admin requests to the list. They will be ignored.
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.