If you look at buddyAPI's file copy with progress command then you might realize that in order to get the progress on copying a file (an asynchronous process) you have to have access to that process/thread. Based off what you're describing, the process of a file that's copying into this folder of yours is occurring outside of your projector's control, so you are not likely going to be able to monitor it's progress.
On top of all that I mentioned above, your description of other copying files to a folder sounds suspiciously like one of two things:
1. Users on the same network copying files to a central file server or a computer acting as a file server.
2. A web-based shockwave project.
Indicating which of the two it is will definitely change the possible solution.
Lastly, the simplest method I can come up with to monitor the file copy process you might have to develop a client application that the users will have to use in order to copy the files to your folder. That way the client app could write to a file in the same folder after the copying is done to indicate that it's done and your app can monitor the folder and that file for file copy status.
This will be an executable application that is accessing a folder on the local network. Some process the client has setup will be copying the zip file into the folder I am scanning for files.
A user on another forum suggested using fileIO to try and open the file in writeable mode and test to see if it opens but that didn't work.
I am looking around to see if there is a method I can use from the command line on windows to access info about the file to monitor it that way.
You can simply try to unzip the file. I don't know how you are doing that in your code, but most xtras that I know of will return an error code if it can not successfully unzip the file. Just keep trying to unzip it until it is successful.
I am using buddyZip to unzip the file which is pretty basic but free. What xtra do you use for unzipping?
Alright I finally figured this out. I found that I can't rename the file till it is finished copying when using BuddyAPI's baRenameFile method. So here is the code that worked for me,
on exitFrame me
if (baRenameFile( oApp.job.srcFile, oApp.job.tmpFile )) then
baRenameFile( oApp.job.tmpFile , oApp.job.srcFile )
So if my source file was c:\test.zip then my tmp file could just be c:\test.zip.tmp . As soon as the rename file happened I would just rename the c:\test.zip.tmp back to c:\test.zip and continue on with what I want to do with that file now that I know it has finished copying.
Cool. Looks like you found a good solution. But I had a look at th docs for BuddyZip and it will return the number of files unzipped or -1 in case of an error. So you couls just check that. But your way will work just as well.
I looked into using the BuddyZip return for the process but I can't rember why it wasn't working for me, I have tried so many things on this script that it is hard to rember it all.
Also it is just nice to have an approach that should work for any type of file.
Thanks to everyone for the input.