MACSCRPT Archives

May 2007

MACSCRPT@LISTSERV.DARTMOUTH.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Andreas Kiel <[log in to unmask]>
Reply To:
Macintosh Scripting Systems <[log in to unmask]>
Date:
Wed, 30 May 2007 11:23:17 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (110 lines)
On 30.05.2007, at 04:21, Stockly, Ed wrote:

>>>> That was(is) not the problem - unfortunately. The problem is to  
>>>> get the file
>>>> size of a file which is still growing  to do the next step with  
>>>> file after the
>>>> file is complete written to disk. All ways of doing that fail if  
>>>> the file name
>>>> is longer than 31 characters, all of them work if not. That's a  
>>>> little odd I
>>>> think.
>
>>>> I tried a shell script, get eof, size of (info). Always same  
>>>> behaviour.
>
> When you say these "fail" what happens?
>
> What is the "same behavior" exibited by shell script, get eor and  
> size of?
error file not found - file name is above 31 chars
>
> Do they generate errors? Do they not return an accurate result?
see above
>
> How large are these files?
from 1 MB (actually then it will work any since the delay in app and  
files are already finished when their file size is requested)
to several GB
> Are they local or network?
Normally they are.
> Are they being sent to their location via FTP or some other process?
No. My app uses GUI scripting to tell another application to start an  
export process with the correct settings. When the file complete my  
app starts a conversion process and sends the result to another  
directory which is monitored by a server application.
While the first app is exporting my app monitors the file size, in  
case the "check file size" loop fails the user has canceled the  
export using the first app.
The loop should only fail if the file disappears - that's the case if  
the export is canceled from out the first app, this kind of failure  
will written to the daily log file with "user canceled file xyz"
Using file names up to 31 characters incl. extension) everything  
works perfect.

> Are you using aliases or strings with the appleScript commands?
>
> I've found that the file commands (open and write at least) seem to  
> be more
> reliable if you're passing aliases as opposed to strings, but that  
> may be my
> imagination.
>
> Alias "drive:dir:file"
>
> As opposed to
>
> File "drive:dir:file"
I tried both without luck.

> Also it might help if you could provide a sample of a command that  
> actually
> fails, complete with file name and path.

		set shellScript to "stat -f %z " & (quoted form of exportFilePath)  
as string
		
		set oldSize to 0
		repeat
			delay 2
			try
				set curSize to do shell script shellScript
				log curSize
				if curSize is oldSize then
					set fullFilePath to exportFilePath
					exit repeat
				end if
				set oldSize to curSize
			on error theError
				log {"error @ file size check run stat script -> user canceled",  
theError}
				set fullFilePath to "User Canceled FCP"
				exit repeat
			end try
		end repeat
		
		-- check again
		set fileExists to (call method "fileExistsAtPath:" of object  
File_Mgr with parameter exportFilePath) as boolean
		log {"fcp file exists", fileExists}
		
		set theLog to theLog & "export finished: " & (current date) & return

Here the modified(shortened) file name and path:
  "/Volumes/SATA_465_01/FCP6 test folder/Sequence 1 C_070530035437.mov"

Here the original(not working) file name and path:
  "/Volumes/SATA_465_01/FCP6 test folder/Sequence 1  
Copy_070530035437.mov"

But as said, to test it you will need a file which is still growing.


> By the way, I subscribe to digest on both lists but didn't see your  
> original
> message on either.
I've no idea why.

Thanks
Andreas

ATOM RSS1 RSS2