R
Story
Things Unix can do atomically (2010)
  • amstan
  • ·
  • 59 minutes ago
  • ·
  • [ - ]
Missing (probably because of the date of the article): `mv --exchange` aka renameat2+RENAME_EXCHANGE. It atomically swaps 2 file paths.
Title says Unix, renameat2 is Linux-only.
  • jasode
  • ·
  • 3 minutes ago
  • ·
  • [ - ]
>Title says Unix,

You're misinterpreting the title. The author didn't intend "Unix" to literally mean only the official AT&T/TheOpenGroup UNIX® System to the exclusion of Linux.

The first sentence of "UNIX-like" makes that clear : >This is a catalog of things UNIX-like/POSIX-compliant operating systems can do atomically,

Further down, he then mentions some Linux specifics : >fcntl(fd, F_GETLK, &lock), fcntl(fd, F_SETLK, &lock), and fcntl(fd, F_SETLKW, &lock) . [...] There is a “mandatory locking” mode but Linux’s implementation is unreliable as it’s subject to a race condition.

You can use `ln` atomicity for a simple, portable(ish) locking system: https://gist.github.com/pwillis-els/b01b22f1b967a228c31db3cf...
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.

  • ptx
  • ·
  • 59 minutes ago
  • ·
  • [ - ]
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...

Not much apparently, although I didn't know about changing symlinks, that could be very useful.
rename() is certainly the easiest to use for any sort of file-system based synchronization.
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?
incron
[dead]
  • exac
  • ·
  • 2 hours ago
  • ·
  • [ - ]
Sorry, there is zero chance I will ever deploy new code by changing a symlink to point to the new directory.
Why? What do you prefer to do instead?
Anything less than an entire new k8s cluster and switching over is just amateur hour obviously
Works pretty well for Nix
  • atmosx
  • ·
  • 6 minutes ago
  • ·
  • [ - ]
Worked pretty well in production systems, serving huge amount of RPS (like ~5-10k/s) running on a LAMP stack monolith in five different geographical regions.

Just git branch (one branch per region because of compliance requirements) -> branch creates "tar.gz" with predefined name -> automated system downloads the new "tar.gz", checks release date, revision, etc. -> new symlink & php (serverles!!!) graceful restart and ka-b00m.

Rollbacks worked by pointing back to the old dir & restart.

Worked like a charm :-)

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

I really liked stow. My toy distro back in the day was based on it.
why? it works and its super clever. Simple command instead some shit written in JS with docker trash
Ah, the memories of capistrano, complete with zero-downtime unicorn handover

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

  • 10us
  • ·
  • 1 hour ago
  • ·
  • [ - ]
Still use php deployer each day and works with symlinks as well. https://deployer.org/
  • alpb
  • ·
  • 1 hour ago
  • ·
  • [ - ]
Nobody's saying you should deploy code with this, but symlinks are a very common filesystem locking method.
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

  • dizhn
  • ·
  • 16 minutes ago
  • ·
  • [ - ]
No snapshotting at all? Thinking about it.. The filesystem does not support it I suppose.
Android does use snapshots: https://source.android.com/docs/core/ota/virtual_ab
  • x4132
  • ·
  • 46 minutes ago
  • ·
  • [ - ]
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?
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