Things Unix can do atomically (2010)

64 points
1/21/1970
3 hours ago
by onurkanbkrc

Comments


amstan

Missing (probably because of the date of the article): `mv --exchange` aka renameat2+RENAME_EXCHANGE. It atomically swaps 2 file paths.

43 minutes ago

oguz-ismail2

Title says Unix, renameat2 is Linux-only.

34 minutes ago

0xbadcafebee

You can use `ln` atomicity for a simple, portable(ish) locking system: https://gist.github.com/pwillis-els/b01b22f1b967a228c31db3cf...

3 hours ago

zzo38computer

Even though it can do some things atomically, it only does with one file at a time, and race conditions are still possible because it only does one operation at a time (even if you are only need one file). Some of these are helpful anyways, such as O_EXCL, but it is still only one thing at a time which can cause problems in some cases.

What else it does not do is a transaction with multiple objects. That is why, I would design a operating system, that you can do a transaction with multiple objects.

an hour ago

ptx

Windows had APIs for this sort of thing added in Vista, but they're now deprecating it "due to its complexity and various nuances which developers need to consider":

https://learn.microsoft.com/en-us/windows/win32/fileio/about...

43 minutes ago

MintPaw

Not much apparently, although I didn't know about changing symlinks, that could be very useful.

2 hours ago

sega_sai

rename() is certainly the easiest to use for any sort of file-system based synchronization.

2 hours ago

ta8903

Not technically related to atomicity, but I was looking for a way to do arbitrary filesystem operations based on some condition (like adding a file to a directory, and having some operation be performed on it). The usual recommendation for this is to use inotify/watchman, but something about it seems clunky to me. I want to write a virtual filesystem, where you pass it a trigger condition and a function, and it applies the function to all files based on the trigger condition. Does something like this exist?

an hour ago

Brian_K_White

incron

an hour ago

exac

Sorry, there is zero chance I will ever deploy new code by changing a symlink to point to the new directory.

2 hours ago

sholladay

Why? What do you prefer to do instead?

2 hours ago

gib444

Anything less than an entire new k8s cluster and switching over is just amateur hour obviously

an hour ago

bandrami

Works pretty well for Nix

an hour ago

mananaysiempre

And for Stow[1] before it, and for its inspiration Depot[2] before even that. It’s an old idea.

[1] https://www.gnu.org/software/stow/

[2] http://ftp.gregor.com/download/dgregor/depot.pdf

an hour ago

bandrami

I really liked stow. My toy distro back in the day was based on it.

25 minutes ago

iberator

why? it works and its super clever. Simple command instead some shit written in JS with docker trash

2 hours ago

lloeki

Ah, the memories of capistrano, complete with zero-downtime unicorn handover

https://github.com/capistrano/capistrano/

2 hours ago

10us

Still use php deployer each day and works with symlinks as well. https://deployer.org/

an hour ago

alpb

Nobody's saying you should deploy code with this, but symlinks are a very common filesystem locking method.

2 hours ago

slopusila

that's how some phone OSes update the system (by having 2 read only fs)

that's how Chrome updates itself, but without the symlink part

an hour ago

x4132

not surprised about the chrome part, but pretty shocked at the phone OS part. I know APFS migration was done in this way, but wouldn't storage considerations for this be massive?

30 minutes ago

slopusila

what would be more massive would be phones not booting up because of a botched update. this way you can just switch back to the old partition

11 minutes ago
×
Sample One
Sample One