Wilfred wrote (2021-09-15):
Hi Oli,
On 2021-09-15 11:38:25, you wrote to Tommi Koivula:
I understand this filebox thing so that if something is put into a
filebox once, it cannot be changed. Any program can read and delete
it any time. So HPT has to create more and more arcmail bundles.
How is that different to arcmail bundles referenced in a FLO file?
Access to files in a regular BSO directory is strictly regulated through the use of lock files (*.csy, *.bsy). So different programs won't access the same files at the same time. There is no such standard for fileboxes.
True, no formal standard. But it's obvious that the program should lock the file before modifying it or when a transfer is in progress. No idea how binkd and hpt handles fileboxes though. I safe strategy would be to lock all files in a filebox when a session starts (at the same time the *.bsy file is written).
As fileboxes usually don't replace BSO, but working in addition to BSO, the program modifying anything in the filebox can create a .bsy file in the BSO.
Of course we cannot rely on such behaviour, because there is no standard. But from the tossers perspective it shouldn't be a problem to safely create / modify 'dailyBundles' in fileboxes. Just create a *.bsy file.
https://en.wikipedia.org/wiki/File_locking
"Windows inherits the semantics of share-access controls from the MS-DOS system, where sharing was introduced in MS-DOS 3.3 . Thus, an application must explicitly allow sharing when it opens a file; otherwise it has exclusive read, write, and delete access to the file until closed (other types of access, such as those to retrieve the attributes of a file are allowed.)"
"Unix-like operating systems (including Linux and Apple's macOS) do not normally automatically lock open files.
[...]
Although some types of locks can be configured to be mandatory, file locks under Unix are by default advisory. This means that cooperating processes may use locks to coordinate access to a file among themselves, but uncooperative processes are also free to ignore locks and access the file in any way they choose. In other words, file locks lock out other file lockers only, not I/O.
[...]
For this reason, some Unix-like operating systems also offer limited support for mandatory locking.[6] On such systems, a file whose setgid bit is on but whose group execution bit is off when that file is opened will be subject to automatic mandatory locking if the underlying filesystem supports it."
---
* Origin: 1995| Invention of the Cookie. The End. (2:280/464.47)