File version numbers à la OpenVMS?

Posted Aug 31, 2021 13:20 UTC (Tue) by Wol (subscriber, #4433)
In reply to: File version numbers à la OpenVMS? by skissane
Parent article: The shrinking role of ETXTBSY

> Many apps would really benefit from these kind of transactional semantics, right now they have to use something like SQLite to get them, but with unit files they could get those semantics directly from the OS.

Again harping on Pr1mos, and I don't know how easy it would be to retrofit to Linux, but files had reader/writer access controls. I don't know whether it was set by the first application to open it, or more likely set in the file system, but you had a choice of "multiple readers (or one writer)", "multiple readers and one writer", and "multiple readers and multiple writers".

So, as it implies, the first person to open the file got it, any other attempts were checked against this lock and the open succeeded or failed depending. When I wrote an accounts package, everything was configured NR&1W, all files were opened read-only unless actually updating the data, and all files were opened in a defined order to prevent deadlocks. (Still didn't prevent one user changing the data underneath another, but the program made sure this didn't matter...)

Cheers,
Wol

File version numbers à la OpenVMS?

Posted Sep 16, 2024 17:38 UTC (Mon) by jch (guest, #51929) [Link] (1 responses)

> Again harping on Pr1mos, and I don't know how easy it would be to retrofit to Linux, but files had reader/writer access controls. I don't know whether it was set by the first application to open it, or more likely set in the file system, but you had a choice of "multiple readers (or one writer)", "multiple readers and one writer", and "multiple readers and multiple writers".

Aren't those just mandatory file locks taken at open time?

File version numbers à la OpenVMS?

Posted Sep 16, 2024 19:12 UTC (Mon) by Wol (subscriber, #4433) [Link]

Reading that again, I'm not sure if I made myself clear, but these were file system attributes. So you had "NR-1W" (either readers OR writer), "NR&1W" (as many readers as you liked, only one writer), and "NR&NW" (as many readers and writers as you liked).

So my accounts system had "NR&1W" set on all files, and only ever opened a file to write when it was doing a commit. There was also always an explicit open hierarchy (as in I only ever opened individual clients after opening the client summary, so I couldn't get a deadlock, same for other ledgers).

So it relied on programming discipline, but could be proven to work if the rules were followed.

Cheers,
Wol