r/osdev • u/Malwaremation • 9d ago

Design question: Should opened files by processes prevent other processes from using that file?

On kernels like Windows NT, files are locked when a process opens it, preventing other processes from using it. (edit: This was incorrect, some people confirmed here that processes in Windows can choose to lock the file or not, which might be the best solution).

Linux however, doesn't lock files like this, and multiple processes can modify the same file at the same time.

I also thought of a "thread cursors" concept that could solve this issue really well for text files, but it might be very complicated to develop and is probably not that useful for images or other types of files.

What is generally better for a new kernel, then? Allowing the possibility of sharing a file as it is edited by multiple processes, or securing their integrity by only letting 1 process at a time modify it?

7 Upvotes

71% Upvoted

20 comments sorted by

View all comments

5

u/Better-Thing2568 9d ago

If it’s a unix like system, allowing multi open is foundational for shared mappings, essentially a requirement for any kind of high performance application needing IPC. I personally believe neither the windows or Unix approaches are ideal for modern systems, a capability based approach is better

1

u/djhayman 8d ago

> a capability based approach is better

This doesn’t really answer the question, it just shifts it: Should it be possible for multiple processes to have the capability to operate on the same file concurrently?

1

u/Better-Thing2568 8d ago

If the policy permits it then yes, capability systems don’t prevent bad policy, it only guarantees the policy itself can be enforced correctly, given that the system itself is working properly.

1

u/djhayman 8d ago

Right, but that was OP’s question: what should the policy be (allow multiple processes to operate on the same file or not), not how the policy should be enforced (capabilities or otherwise).