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. Disappearing is part of their specification, so they cannot live somewhere that forbids it.

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 uses a fixed name so it cannot pile up per run.
supports_full_lifecycle() {
  local dir="$1" probe
  if [ -z "$dir" ] || [ ! -d "$dir" ] || [ ! -w "$dir" ]; then return 1; fi
  probe="$dir/.lifecycle_probe"
  # A leftover probe means this location already failed the test
  if [ -e "$probe" ]; then return 1; fi
  if ! mkdir "$probe" 2>/dev/null; then return 1; fi
  if ! rmdir "$probe" 2>/dev/null; then 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; rm -f "$LOCK_FILE" 2>/dev/null' EXIT
 
[ -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 the probe name is fixed. A rejected location keeps exactly one probe artifact, and 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.

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.

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 probe artifact 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.