The lock I left in a shared folder shut out every run after the first

Three lock styles, each run twice

There are three common ways to implement a lock. I ran each of them twice in a row in the same connected folder. For unattended work, the second run is the one that matters.

# 1. mkdir lock (existence-based)
for run in 1 2; do
  if mkdir "$SHARED/mkdir.lock" 2>/dev/null; then
    echo "run$run: acquired"
    rmdir "$SHARED/mkdir.lock" 2>/dev/null \
      && echo "run$run: released" || echo "run$run: could not release"
  else
    echo "run$run: could not acquire"
  fi
done

For the first two, the lock is the existence of a file or directory. Where deletion is refused, a lock taken once is never given back. The very first run seals the slot against every future run.

flock behaves differently because the exclusion lives on the open file descriptor, not on the file's existence. When the process exits, the descriptor closes and the lock is gone. Even though I could not delete the file, the next run acquired it without trouble. All that remains is one empty file.

That settled which style belongs in unattended work. If you have no choice but to store the lock somewhere undeletable, existence-based locks are off the table.

When migrating a job that already runs on an existence-based lock, this order kept production running for me.

1. Check whether deletion works where the lock currently lives. If it does, there is no urgency
2. Switch to flock and move only the location to local, run-private storage. Leave the acquisition logic alone
3. Confirm from the ledger's skip count that no old artifact is still locking the slot out

Reversing that order means carrying the leftovers into the new scheme, which makes diagnosis harder. I tried to slip a workaround in at this point and only added more state to verify. If you do adopt an existence-based lock, I recommend confirming first that deletion goes through where you plan to put it.

"Could not acquire" and "someone is running" are different facts

The nastier half of this was how the failure presented itself.

An existence-based lock cannot distinguish a live holder from a dead one. When mkdir fails, the only information you get is "it already exists." Whether that came from another process three seconds ago or from a leftover three weeks old is not recoverable.

And most implementations read that state as "the previous run must still be going" and exit cleanly. Exit code 0, one line in the log, no alert. That was exactly my morning: the work had stopped, but nothing in the record looked broken.

I considered writing a PID into the lock file to tell the two apart, but it does not help in this setup. Each unattended run happens in a separate sandbox, so comparing a recorded PID against the current process table is meaningless — you get a number that does not exist here.

The dividing line is refusing to treat a skip as a clean finish. I have written about the broader shape of silent stoppages in why Cowork scheduled tasks stop without a sound, and how to build recovery that stands back up on its own.

Why deletion in particular is refused

For a moment I wanted to file this under environment bug. The more I looked, the more sense it made.

A connected folder is the real working folder you handed over. It holds drafts, settings, records. Letting an automated process create and append while routing deletion through a human decision is a clean line: the irreversible accidents mostly live on the delete side. Rename passing the same check fits the same logic. A renamed file can be found again; a deleted one cannot.

So the boundary was drawn from the direction of the accident it prevents. Not something to resent — something to design around.

That same premise shapes what belongs in a connected folder at all. When I counted what was actually sitting in mine before handing it over, the results are in I counted the keys in a folder before giving it to an AI: filenames found 5 of 18. What is safe to place there and what becomes unrecoverable the moment you place it are two separate questions.

Sort storage by lifetime, not by sharedness

Once the cause was clear, I changed the criterion for where things go from "is it shared?" to "how long should it live?"

Ledgers and logs are arguably safer in a place that refuses deletion. They are append-only anyway, so the restriction costs nothing. Appends to the connected folder went through without issue in my environment.

Locks are the opposite. They are short-lived by nature, born and finished with every run, so they cannot live somewhere that refuses cleanup.

An implementation you can run

I made the script decide where the lock goes at runtime — not by checking existence, and not by checking writability, but by checking whether cleanup completes.

#!/usr/bin/env bash
# Single-instance lock for unattended runs.
# Never place the lock anywhere that refuses deletion.
set -uo pipefail
 
SLOT="${1:?slot name required}"        # e.g. nightly-report
SHARED_LEDGER="${SHARED_LEDGER:-}"     # append-only; a connected folder is fine
 
# Candidate lock roots, private and local first
lock_root_candidates() {
  printf '%s\n' \
    "${XDG_RUNTIME_DIR:-}" \
    "/run/user/$(id -u 2>/dev/null || echo 0)" \
    "${TMPDIR:-/tmp}" \
    "$HOME/.cache"
}
 
# Verify that both creation and removal go through.
# The probe directory carries the PID, so concurrent starts cannot collide.
# A location that fails cleanup gets one fixed-name marker, once
supports_full_lifecycle() {
  local dir="$1" probe
  if [ -z "$dir" ] || [ ! -d "$dir" ] || [ ! -w "$dir" ]; then return 1; fi
  # A marker means this location already failed the test
  if [ -e "$dir/.no_cleanup_here" ]; then return 1; fi
  probe="$dir/.lifecycle_probe.$$"
  if ! mkdir "$probe" 2>/dev/null; then return 1; fi
  if ! rmdir "$probe" 2>/dev/null; then
    : > "$dir/.no_cleanup_here" 2>/dev/null
    return 1
  fi
  return 0
}
 
pick_lock_root() {
  local d
  while IFS= read -r d; do
    if supports_full_lifecycle "$d"; then printf '%s\n' "$d"; return 0; fi
  done < <(lock_root_candidates)
  return 1
}
 
LOCK_ROOT="$(pick_lock_root)" || {
  echo "FAILED: no location accepts a lock (nothing allows deletion)" >&2
  exit 3
}
 
LOCK_FILE="$LOCK_ROOT/unattended-$SLOT.lock"
exec 9> "$LOCK_FILE" || exit 3
 
if ! flock -n 9; then
  echo "SKIPPED: $SLOT is held by another process" >&2
  [ -n "$SHARED_LEDGER" ] && printf '%s\t%s\t%s\t%s\n' \
    "$(date -Iseconds)" "$SLOT" "$$" "skipped" >> "$SHARED_LEDGER"
  exit 2                      # do not exit 0
fi
trap 'flock -u 9 2>/dev/null' EXIT      # never delete the lock file
 
[ -n "$SHARED_LEDGER" ] && printf '%s\t%s\t%s\t%s\n' \
  "$(date -Iseconds)" "$SLOT" "$$" "acquired" >> "$SHARED_LEDGER"
 
# ---- your actual work goes here ----
 
[ -n "$SHARED_LEDGER" ] && printf '%s\t%s\t%s\t%s\n' \
  "$(date -Iseconds)" "$SLOT" "$$" "released" >> "$SHARED_LEDGER"
exit 0

Throwing a second run at it while the first holds the lock ends like this:

SKIPPED: nightly-report is held by another process
second run exit=2

And the ledger accumulates:

2026-08-29T12:14:57+0900	nightly-report	22	acquired
2026-08-29T12:14:57+0900	nightly-report	34	skipped
2026-08-29T12:15:00+0900	nightly-report	22	released

One thing only became obvious after I had written it. In a location that refuses cleanup, this probe cannot clean up its own probe. The routine for detecting "cleanup does not work here" needs cleanup — a slightly comic arrangement.

That is why a location that fails cleanup keeps one fixed-name marker. The next run sees it, creates nothing, and returns the same verdict. Leaving one artifact for the lifetime of the folder is a very different thing from leaving one per run.

I only reached this shape after stepping into a sizeable hole in my first version, which the next section records.

The gap between checking existence and actually attempting the operation is covered from another angle in passing an existence check does not mean you can write there.

When I ran two copies at once, my first version broke first

Every test up to this point ran one copy at a time. I had checked a lock implementation by running a single process. Embarrassing, but only when I started two at the same moment did I find that my first version had two holes.

The test is small. In place of the real work, put something that detects two processes inside at once.

# stand-in for the real work: record OVERLAP if someone is already inside
if ! mkdir "$OUT/guard" 2>/dev/null; then
  echo OVERLAP >> "$OUT/overlap.log"
else
  sleep 0.01; rmdir "$OUT/guard"
fi
 
# start two at once, 200 times
for i in $(seq 1 200); do ./lock.sh t & ./lock.sh t & wait; done

Results from my environment (a 4-core Linux sandbox, with two local run-private directories as candidates).

The first hole was the fixed probe name. When two processes run mkdir at the same instant, one of them lands on "a probe already exists" and judges the location a failure. The two then put their locks in different places and ran together without ever seeing each other. The fixed name, meant to keep artifacts from piling up, was breaking the exclusion itself.

The second was removing the lock file on exit. The moment the first process releases and deletes it, a second process that had already opened the old file can take the lock on a file that no longer has a name. A third process then creates a new file under the same name and locks that too — two locks, one name. This article says flock does not depend on a file's existence, and I had been using flock while adding a cleanup step that did.

The fix was small: put the PID in the probe directory name, and stop deleting the lock file. That is all.

A lock passes only after it survives two copies started at the same moment, not after it works once.

This test ran on local storage. The branch for locations that refuse deletion (leave a marker, move to the next candidate) relies on the measurements from the connected folder shown earlier. Counts will vary by environment, so I would look less at the numbers than at the fact that they do not reach zero.

Make a skip something the record remembers

Splitting the exit codes was about eliminating windows where nothing is heard.

Counting ledger lines surfaces trouble quickly. An acquired with no matching released means a run grabbed the lock and died holding it. A wall of skipped with nothing holding anything means the job has been standing aside for no reason.

awk -F'\t' '
  $4=="acquired" { open[$3]++ }
  $4=="released" { open[$3]-- }
  $4=="skipped"  { skip++ }
  END {
    for (p in open) if (open[p] > 0) print "unreleased:", p
    print "skips:", skip+0
  }
' "$SHARED_LEDGER"

I fold this output into my morning check. If the number reaches double digits, I treat that slot as not running.

What I deliberately did not automate

A few things I chose to leave out, and why.

There is no stale-lock breaker. With flock you do not need one, because the lock dies with the process. Adding a breaker means adding something that can misfire and permit double execution. Capabilities you do not need are safer left out.

I do not auto-clean the connected folder either. Routing deletion through human judgement is the design; working around it for my own convenience defeats the point. One empty marker remains for the lifetime of the folder, and deciding whether to remove it is a decision I can make myself.

And I leave other sessions' files alone. Another unattended run may be active on the same machine, and its temp files are not mine to tidy.

One thing worth checking today

If you have anything running unattended, there is a single check worth doing now. In the directory where your lock file lives, try one delete.

: > "$(dirname "$YOUR_LOCK_FILE")/.rm_check" && \
  rm -f "$(dirname "$YOUR_LOCK_FILE")/.rm_check" && \
  echo "deletion works here" || echo "do not put a lock in this location"

If it passes, your current setup is fine. If it does not, there is a real chance the second run never started. It cost me a night and a bit to work that out, and I would be glad if it saved someone else the same evening.