The permissions on the parent and lock directory could restrict the access to a specific user and group, but yes, other processes could interfere with this locking if directed to do so.
One condition where this interference is helpful is a crash, where a @reboot entry in the crontab could:
[ -d /your/lockdir ] && rmdir /your/lockdir
You would also not want to place the lock directory in /tmp or otherwise where other users could manipulate (or see) it. In Red Hat, there is a /var/run/lock directory that might be appropriate.
My biggest use case for directory locking in scripts is handling inotify events.
was just wondering, could something else remove the dir in between the if and then, before trap?
Just wondering about the atomicity.
One condition where this interference is helpful is a crash, where a @reboot entry in the crontab could:
You would also not want to place the lock directory in /tmp or otherwise where other users could manipulate (or see) it. In Red Hat, there is a /var/run/lock directory that might be appropriate.My biggest use case for directory locking in scripts is handling inotify events.
With this one, it was "Wow, $foo was a simpler problem than I thought and Unix (and thus Linux and OSX) just totally screwed it up for no reason"
You know things are bad when the least awful implementation of OS-level locking is the one from Microsoft.