### Summary A critical bug in the `FileCreate` function causes a double `FileClose` call with the same descriptor (`EBADF` error) if file locking fails. This is highly dangerous in multithreaded applications, as one thread can accidentally corrupt or close a file descriptor currently assigned to and used by another thread. Additionally, the `fpflock` retry loop in `DoFileLocking` is implemented incorrectly, and there are redundant `fpClose` loops in `sysutils.pas`. ### System Information * **Operating system:** Linux (Astra Linux) * **Processor architecture:** \[x86-64\] * **Compiler version:** \[3.2.2 / trunk\] * **Device:** Computer ### Steps to reproduce The issue occurs under high file I/O intensity when `DoFileLocking` fails to acquire a lock. 1. Create a scenario with high intensity file operations across multiple threads. 2. Trigger a condition where `DoFileLocking` fails to lock the file and returns an `EAGAIN` error. ### Example Project An example project is not attached, but the issue can be seen directly in the source code analysis below. ### What is the current bug behavior? 1. **Double Close:** The root cause is an incorrect sequence of function calls: ```pascal Result:=DoFileLocking(fd,ShareMode); FileClose(fd); ``` If `DoFileLocking` fails to lock the file, it closes the descriptor `fd` internally. After that, the exact same descriptor is closed a second time by the subsequent `FileClose` call. 2. **Incorrect Retry Loop:** The `fpflock` loop in the `DoFileLocking` function exits immediately on the first locking error and throws a "Try again" exception instead of retrying. 3. **Redundant Loops:** There are several places in the `sysutils.pas` module where `fpClose` is called inside a loop to retry on system interrupts (`EINTR`). For Linux, these repeated calls are incorrect and also lead to double closing of file descriptors. ### What is the expected (correct) behavior? 1. `FileClose(fd)` should not be called if `DoFileLocking` has already closed the descriptor. 2. The `DoFileLocking` loop should properly retry on transient errors. A more robust implementation would look like this: ```pascal TryCount := 0; repeat lockres:=fpflock(Handle,lockop); if (lockres <> 0) and (fpgeterrno = ESysEAGAIN) then begin Inc(TryCount); if TryCount > 30 then Break else Sleep(1); end; until (lockres=0) or ((fpgeterrno<>ESysEIntr) and (fpgeterrno<>ESysEAGAIN)); ``` 3. Redundant `fpClose` loops handling `EINTR` on Linux should be removed or corrected, as Linux does not require restarting `close()` after `EINTR`. ### Relevant logs and/or screenshots An example of the locking failure from system logs: ```text flock(15, LOCK_EX|LOCK_NB) = -1 EAGAIN (Resource temporarily unavailable) ```