[fpc-other] disk "glasses"

[Hans-Peter Diettrich]

Just a view notes on your fine contribution:

Roland Schäfer schrieb:
> On 08/13/2014 09:58 AM, duilio foschi wrote:
>>> but having two or more applications that concurrently write to a single file is a bad(TM) idea
>> all operating systems and all db services like VirtualBox, Firebird
>> etc allow that.
> 
> (1) Operating systems may allow you to access files from more than one
> process, but they do not guarantee that this doesn't ruin your files in
> terms of making inconsistent changes. On encrypted files, especially
> large ones, the damage would be even worse (i.e., most likely total and
> highly unrecoverable).

File access is more a matter of network and *file systems*, the OS only 
must provide minimum support (integration...) for such extensions. 
That's the way how e.g. file and volume encryption is implemented.

Concurrent file operations and file integrity is left to the file user 
(processes). The OS provides file locking mechanisms, but the user can 
allow or deny concurrent file access when opening an file. Similarly the 
user (admin) can specify access rights on volumes or files, the OS and 
file systems only provide such managment features.


> (2) I'm not sure how VirtualBox fits in here. If you mean that it allows
> you to access files from host and guest system simultaneously, then see (1).

Virtual Machines typically offer network connections, which allow for 
file access in both directions. Again it's the user (admin) who grants 
access rights, establishes shares etc. The user can effectively "unplug" 
the network connections of a VM, so that no data can be transferred into 
(viruses...) or out of (file copy...) a VM. But it should be kept in 
mind that the volumes of a VM are stored as drive image files on the 
host machine, so that these files also must be protected against attacks 
(by access rights). Encryption can be applied to the file system(s) 
inside the VM, then the disk images on the host machine contain 
encrypted information, and no further encryption is required then.


> (3) Database products allow you to access DATA BASES from several
> processes/clients via their engine (e.g., a through a local or web
> service). This is entirely different from accessing FILES simultaneously
> from independent processes – and one of the aspects that makes writing
> database applications complicated.

Databases come in single-user or multi-user flavors. Multi-user 
databases typically use a client-server model for data access, where the 
server handles concurrent requests from the client processes. While a 
single-user DB software protects the DB files only while the DB is used 
by an process, a multi-user DB may establish a permanent lock, once a 
server has been started.

I've used an similar mechanism already, by opening a couple of critical 
files in a dedicated application, so that these locked files could not 
be replaced by other processes. That application could disallow read 
access as well, but then it should become a file server, because 
otherwise no other user program could use the locked files.

DoDi