File locking, share modes and concurrent access

File locks and open-handle sharing rules coordinate concurrent operations, while permissions and file completeness remain separate questions.

A media file can exist and be readable while another process is still writing it. Whether a reader can open it depends partly on the writer's open mode and any locking arrangement.

This matters during imports, recordings and metadata updates. A failed open may reflect an incompatible existing handle, even when the server identity has permission to read the file.

Permissions do not describe concurrent handles

Permissions determine whether an identity may request an operation. A lock or sharing rule coordinates that operation with other activity. A process can pass the permission check and still fail because another process has established an incompatible state.

On Windows, CreateFile includes both the access requested by a new handle and the access it permits other handles to share. Compatibility is checked in both directions against existing opens. A writer can allow readers to coexist, or omit read sharing and cause a later read open to fail with a sharing violation.

On Linux, ordinary flock locks are advisory: cooperating processes request shared or exclusive locks. A local reader that ignores the advisory mechanism is not automatically prevented from reading simply because another process holds such a lock. Different lock APIs and remote file systems can have different interactions.

An importer and a reader

An original Windows-style scenario declares the relevant handle choices:

Existing importer: requests WRITE; shares READ
New player:        requests READ;  shares READ and WRITE
Read open:         compatible with these stated access/share choices

Existing importer: requests WRITE; shares no access
New player:        requests READ;  shares READ and WRITE
Read open:         incompatible

The model omits delete access, other handles and detailed API flags. Its purpose is to show that permitting shared reads changes concurrency, not the content's completeness.

If the first read succeeds, it may still encounter only the bytes written so far. A media container may lack final indexes or have fields awaiting completion. A recording that is still growing is not equivalent to a finished import.

Several completion conditions

Observation Meaning
File can be opened Current access and sharing checks permit the open
Writer closes its handle That handle has finished its activity
File is renamed to its final name A naming operation has occurred
Application reports a successful import The application's completion rule has been met
Required data and metadata are synchronized The requested durability contract has completed

A workflow can deliberately write under a temporary name and rename when ready. That offers a clearer publication point than asking whether the visible file has stopped growing for a short interval. The exact guarantees depend on the operation and storage. A rename within one file system and a transfer between volumes are not automatically the same operation.

Network file access adds protocol behavior

SMB implements open/share state and caching coordination. NFS versions and implementations have their own locking, state and recovery rules. Local API behavior can be translated into remote protocol operations, so a local advisory-lock explanation should not be assumed to describe every mounted share.

For an Emby scan error, identify the failed operation and its result: permission denied, sharing violation, timeout and incomplete media parsing mean different things. The fact that a file later plays successfully can be consistent with an earlier scan encountering an in-progress or conflicting operation.

See Also

References