MacOS – Bash script with lock folder problems for large files

bashcronmacosscript

My script is:

#!/bin/bash

    # Path to a lock folder
LOCK_PATH="/Volumes/PROOFS_WATCH/copy.lock"

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"
fi

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
logout
[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.

Best Answer

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:

…
else
    echo "Lock exists."
fi

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
Related Question