Under Mac OS X v10.1.1, Mac Python does not seem to
handle a findertool move command.

old:  Macintosh HD:Desktop Folder:downloads:
new: Macintosh HD:Desktop Folder:downloads:Achikatactics
filename: ACHIKA_TACTICS_2_00.JPG
old + file: Macintosh HD:Desktop
Folder:downloads:ACHIKA_TACTICS_2_00.JPG
Traceback (most recent call last):
  File "OS v9.1:Desktop Folder:python
work:re-dup-file.py", line 104, in ?
  File "OS v9.1:Desktop Folder:python
work:re-dup-file.py", line 53, in move_file
  File "OS v9.1:Applications (Mac OS 9):Python
2.1.1:Mac:Lib:findertools.py", line 74, in move
  File "OS v9.1:Applications (Mac OS 9):Python
2.1.1:Mac:Lib:lib-scriptpackages:Finder:Standard_Suite.py",
line 293, in move
aetools.Error: (0, 'component result = no error', None)

The file *does* get moved, but the above trace is reported.

I'll append the actual code, once I boot back to OS 9.

The same code *DOES* work under OS 9... (So it is
restricted to Mac OS X 10.1.1).  

I do not *REMEMBER* seeing the problem in earlier
versions of Mac OS X, but that is suspect.  (I can't
say for certain that it doesn't appear).

    - Benjamin

Logged In: YES 
user_id=3811

This is the code that is producing the error...

Please keep in mind, it works fine in OS 9.x.x or earlier 
under MacPython.  Only under MOSX does it appear to fail.
(Even then the file does get moved, but an exception is 
raised).

def		move_file ( old_path, new_path, filename ):
#			try:
				print "---------------------
----------------"
				print "old: ",old_path
				print "new:",new_path
				print "filename:",filename
				print "old + file:", 
old_path + filename

				if os.path.exists (new_path 
+ os.sep + filename):
					Ask = 
EasyDialogs.AskYesNoCancel("Duplicate File Detected (%s), 
Overwrite?" % filename, default = 1, yes=None, no=None, 
cancel=None, id=262)
					if Ask == 1:
						if mac_mode:
							# 
Overwrite, by removing the old file
							#
						
	os.remove(new_path + os.sep + filename)
							
					elif Ask == 0:
							#
							#
	Do not overwrite, end routine, by returning
							#
						return 0
						
					elif Ask == -1:
							#
							#
	Abort program, return error code
							#
						return -1
				
				if mac_mode:
					findertools.move 
(old_path + filename, new_path)
#			except:
#				pass
			
#			return None
		

Logged In: YES 
user_id=45365

My feeling is that the problem is with the finder, not with Python. The 10.1.1 finder apparently returns an 'errn'
parameter (keyErrorNumber) with value 0. My interpretation (and every other scriptable app in the world) does not return any 'errn' parameter in the no-error case.

I suggest you file this as a bug with Apple. If they won't fix it I'll do so (reluctantly;-). In the mean time you can work around the problem by replacing all the 
    if has_key(_arguments, 'errn'):
with
    if has_key(_arguments, 'errn') and _arguments['errn'] != 0:

Logged In: YES 
user_id=45365

Fixed a while ago (the fix is already in 2.2.1): even though the Finder is incorrect IMNSHO the suite modules have been regenerated to treat a 0 "errn" return value the same as a missing "errn" (i.e. no error).

Logged In: YES 
user_id=45365

Erik van Blokland pointed out that the fix is not in 2.2.1 yet. It is on the release22-maint branch, however, so it will be in 2.2.2.