Thank you for your post.
I have forwarded your entire post to our Software Quality Assurance (Testing) department to confirm and gather more information. When I receive additional information, I will let you know.
Pay attention to the last line char. It's not a smile, but a curve bracket, so I've added a space between " and )
Unfortunately the editor treats this chars pair as a smile!
ditto -ck --sequesterRsrc $sourceDir $destDir$dbName$(date "+_%Y_%m_%d|%H%M.zip" )
Yes, I was aware that there was a closing parenthesis. However, thank you for making the clarification.
Here is the latest information from our Testers:
1. Stop DBS
2. Get Info on Backup drive
3. Place check mark on ignore ownership on this volume
4. Restart DBS
5. If script continues to fail, navigate to folder /HISTORIC then --> Get Info. Change Staff to read/write although you should not need this step.
6. Validate the items exist in folder lastBackup or source folder
Possibilites for script no longer running... Open script in script editor and enable invisible file option. Look for any extra characters that might cause the script to fail.
Logviewer information when source folder is empty: Schedule "SchedName" abort; aborted by users
Logviewer information when ignore ownership on this volume is unselected on partition volume: Schedule "SchedName" abort; aborted by user
Let me know if this helps.
Thank You moderator (and Tech-Staff) for this reply!
I've performed all your suggestion, but all those scripts still fail.
In my opinion FMS10 dislikes the way DITTO works!
As I've written before, these script work fine if started from Terminal/X11, not from FMS.
So I've changed my way and replaced DITTO with ZIP!
My script now looks this way and works fine :
------------ start ----------
zip -rjq -7 $destDir$archiveName$(date "+_%Y_%m_%d|%H%M.zip" ) $sourceDir -i \*.fp7
------------ end ---------
BTW there is still something not clear: "why my previous script was working fine with FMS9 and not with FMS10.
The case is still open!
I'm glad you were able to get this working.
Here is the latest information from the Testing department.
The script was copied verbatim, and if the permissions are set correctly, it works.
Have the customer use full path names in the script for the utility being used. For example,
from the terminal window, type: which ditto
Example out: /usr/bin/ditto
so add below to the shell script:
ditto /usr/bin/ditto -ck --sequesterRsrc $sourceDir $destDir$dbname$(date "+_%Y_%m_%d|$H%M.zip" )
The updating from FileMaker Server 9 to FileMaker Server 10 with existing or prior scripts was tested and found to work after the upgrade. With FileMaker Server 9, if the script is launched, there would not be an error message. If there is a problem with the script, it would not be logged. FileMaker Server 10 is a bit more restrictive, and the error from the script is captured.
Both DITTO and Zip utilities are at times problematic depending on the OS version, system updates, etc. As an example on the varying problems with some of the tools and the differences in versions you can see by using MD5 on a file from OS X 10.3/OS X 10.4/OS X 10.5 that your results will usually be different.