My script is:


    # Path to a lock folder

trap 'rmdir "$LOCK_PATH"; exit' 1 6 15

if mkdir "$LOCK_PATH"; then
    echo "Lock file did not exist and was created, Copying..."

        # Perform commands
    cp /Volumes/PROOFS_WATCH/*.mov /Volumes/PROOFS_WATCH/AME_Processing/
    cp /Volumes/PROOFS_WATCH/*.mov /Volumes/PROOFS_TV
    rm /Volumes/PROOFS_WATCH/*.mov 

        # Remove the lock
    rm -f "$LOCK_PATH"

My Output is:

Lock file did not exist and was created, Copying...
cp: /Volumes/PROOFS_WATCH/*.mov: No such file or directory
cp: /Volumes/PROOFS_WATCH/*.mov: No such file or directory
rm: /Volumes/PROOFS_WATCH/*.mov: No such file or directory
rm: /Volumes/PROOFS_WATCH/copy.lock: is a directory
[Process completed]

rm -f does not remove the lock folder for some reason...

I would like this script to run automatically via Cron every 60 seconds. If a large file is being written though I don't want it to run until the file write is complete.

Im realizing more of what can be done with bash and I want to automate more processes as well.

  • 1
    yo remove directories rm -r or rmdir
    – mmmmmm
    Aug 4, 2015 at 18:46

1 Answer 1


Fixing the Lock Removal

Try using rmdir to remove the lock folder:

rmdir "$LOCK_PATH"

Debugging Paths

To debug the cp paths, try this command in Terminal.app:

open /Volumes/PROOFS_WATCH/

Does the expected folder open? Play around with the path until open displays the expected folder in the Finder.

To debug the lock folder, try running the script in two Terminal.app windows. Do they both try and copy? Trying adding an else statement to see if mkdir is working as desired:

    echo "Lock exists."

Debugging Shell Scripts

Take a look at How to Add Error Checking to Your Shell Scripts to help identify any problems.

Hard Links

Mentioned in comments below is a new constraint: other applications may be writing the files as this script is running. This script can not block other applications changing or writing to the affected folders.

If a file is being written to, then the cp will only see and copy a partial file. The next time the script runs, the file will likely be fully available and copy correctly. This may or may not be acceptable.

If the copy occurs on the same physical volume, the copy can likely be avoided. In place of a copy, consider creating a hard link with the ln tool:

ln <source_file> <target_file>
ln [-Ffhinsv] <source_file> ... <target_dir>

The link does not copy any data and is almost instant. Changing either the original file or the newly hard linked file will be reflected in both.

Try creating a hard link by hand before attempting to change the script:

ln /Volumes/PROOFS_WATCH/movie.mov /Volumes/PROOFS_WATCH/AME_Processing/movie.mov
  • Ok, so paths are good, rmdir works, everything is running fine... but when I test it with a large file, it does not stop the script from copying the file before its done... It just copies away before the file write is complete.
    – Brian
    Aug 4, 2015 at 19:38
  • I have updated the answer with an else suggestion and how to add more error checking. Hope this helps! Aug 4, 2015 at 19:46
  • Hey Graham! So Ive gone through, error checked everything, and its working perfectly now! You were extremely helpful! However Ive realized that this script only offers protection against running the script, then waiting for a long copy, then the script running again. Which is great! And its a great feature to have, but I realized my problem still exists because if my large file is still being written by another application and the script runs the script will still execute, create the lock folder, and copy the file, thus corrupting it. l think I will still have to use LSOF or similar.
    – Brian
    Aug 5, 2015 at 12:52
  • I will mark this as answered and ask another question. Thanks again! I really appreciate your efforts and knowledge.
    – Brian
    Aug 5, 2015 at 12:53
  • If the files are on the same physical volume, try replacing the copy with the creation of a hard link. This may help overcome partially written files – assuming files are being written in place by the application. Aug 5, 2015 at 13:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .