3 ms·

> Why everything which doesn't work as someone expected is called "damned"? Because POSIX doesn't provide features that are necessary for reliability. Workarou

by zvrba 4y ago

> Why everything which doesn't work as someone expected is called "damned"? Because POSIX doesn't provide features that are necessary for reliability. Workarounds, if they exist, are highly platform-specific. That I'd say is damnation of the standard. For example, how do you, within POSIX, ensure that a write to the storage media is "durable"? People argue about what combination of various "sync" calls and open flags you need to achieve this. (Disregard the case of hardware cheating -- nothing can be done about that.) How do you make an "owning" lock on a file: a kind of that you and only you (the owner) can remove? Why is a lock applied per for file descriptor and not the file object? What is the workaround here? In general, POSIX + threads = damnation because there's too much per-process global state, which was kind of OK "before MT". It's clear that the standard was written before multithreading was even foreseen to be the norm, and it contains many SNAFUs wrt threads, not just files. (Signals and fork are the first to come to mind.) Oh, yeah, don't mention Linux. It has so many extensions and additions to POSIX to alleviate POSIX messups that it's not even funny.

GauntletWizard 4y ago
In posix, you call "sync". Everything beyond that is workarounds for hardware and software level cheating. There are good reasons that modern filesystems aren't quite as simple as that, and some of those reasons are shameful, but it's not on POSIX. Edit: I just reread the spec, and it is on POSIX: They recognized that "sync" was not actually writing, and documented the real usage. Unix 5 has this to say about sync: > Sync causes all information in core memory that should be on disk to be written out..This includes modifi~ super blocks, modified i-nodes, and delayed block I/0. > It should be used by programs which examine a file system, for example check, d.£ etc. It is mandatory before a boot. But by System 6, Lion's book is already referring to the peculiarities of delayed writes.
- jmalicki 4y ago
  There was also the entire fiasco where postgres and Linux kernel developers discovered it was damn-near impossible to get the intended behavior with fsync as there were way too many pitfalls, underspecification, and filesystem-level incompatibilities to know what happened in the non-happy case. https://www.postgresql.org/message-id/CAMsr+YHh+5Oq4xziwwoEfhoTZgr07vdGG+hu=1adXx59aTeaoQ@mail.gmail.com https://www.postgresql.org/message-id/CAMsr+YHh+5Oq4xziwwoEf...
ufmace 4y ago
Seems to me, it's a lot tougher to make all of this stuff always work right in the face of buggy or hostile programs. If you have a super-serious hardcore owner lock on a file that only the opening process can release, what happens when a buggy or hostile program locks a file and never unlocks it, even after exiting?
- imtringued 4y ago
  There is nothing more beautiful than not being able to delete malware because it is currently running.

by zvrba 4y ago

GauntletWizard 4y ago

In posix, you call "sync". Everything beyond that is workarounds for hardware and software level cheating. There are good reasons that modern filesystems aren't quite as simple as that, and some of those reasons are shameful, but it's not on POSIX. Edit: I just reread the spec, and it is on POSIX: They recognized that "sync" was not actually writing, and documented the real usage. Unix 5 has this to say about sync: > Sync causes all information in core memory that should be on disk to be written out..This includes modifi~ super blocks, modified i-nodes, and delayed block I/0. > It should be used by programs which examine a file system, for example check, d.£ etc. It is mandatory before a boot. But by System 6, Lion's book is already referring to the peculiarities of delayed writes.

jmalicki 4y ago
There was also the entire fiasco where postgres and Linux kernel developers discovered it was damn-near impossible to get the intended behavior with fsync as there were way too many pitfalls, underspecification, and filesystem-level incompatibilities to know what happened in the non-happy case. https://www.postgresql.org/message-id/CAMsr+YHh+5Oq4xziwwoEfhoTZgr07vdGG+hu=1adXx59aTeaoQ@mail.gmail.com https://www.postgresql.org/message-id/CAMsr+YHh+5Oq4xziwwoEf...

ufmace 4y ago

Seems to me, it's a lot tougher to make all of this stuff always work right in the face of buggy or hostile programs. If you have a super-serious hardcore owner lock on a file that only the opening process can release, what happens when a buggy or hostile program locks a file and never unlocks it, even after exiting?

imtringued 4y ago
There is nothing more beautiful than not being able to delete malware because it is currently running.