What are file descriptors on Linux and handles on Windows? How does .NET manage them, and why does SafeHandle exist?

1. What the kernel keeps

On Linux there are three layers:

per-process fd table ──► open file description ──► inode / socket
    (fd 3)                 (offset, flags O_APPEND)     (the actual file)

• dup(fd) or fork gives a second descriptor pointing to the same open file description, so they share the file offset.
• Opening the same path twice gives two descriptions with independent offsets.
• When the last descriptor to a description closes, the kernel releases it. If a file was deleted while open, its disk space is only freed then (a classic "disk full but du says otherwise" puzzle).

Windows is similar: the handle table entry points to a kernel object with a reference count, and the object goes away when the count reaches zero.

2. Limits

ulimit -n          # soft limit for this shell
ulimit -Hn         # hard limit
cat /proc/<pid>/limits | grep "open files"
cat /proc/sys/fs/file-max   # system-wide

systemd services use LimitNOFILE= (modern systemd defaults the soft limit to 1,024 and the hard limit to 524,288 so programs can raise their own). Docker inherits the daemon's limit unless you pass --ulimit nofile=.... .NET raises its soft limit to the hard limit at startup on Linux, so the hard limit is what usually matters.

3. Why raw IntPtr was not enough

Early .NET used IntPtr for handles. Three problems:

1. Leaks on async exceptions: if a thread abort hit between CreateFile returning and storing the value, the handle leaked forever.
2. Finaliser ordering: a class's finaliser might run while another finaliser still uses the handle.
3. Handle recycling: thread A passes handle 0x44 into a P/Invoke; thread B calls Close on it; the OS reuses 0x44 for a new file; thread A's native call now writes to the wrong file. This is a security bug, not just a crash.

SafeHandle fixes all three:

• It derives from CriticalFinalizerObject, so its finaliser runs after normal finalisers and is prepared ahead of time.
• The marshaller calls DangerousAddRef before a P/Invoke and DangerousRelease after, so Close during a call only marks it for release; the real close happens when the call finishes.
• ReleaseHandle() is the one place that calls close/CloseHandle.

4. Writing your own

You rarely need to, but for a native library you would subclass SafeHandleZeroOrMinusOneIsInvalid and override ReleaseHandle. With LibraryImport (source-generated P/Invoke), you can return the SafeHandle type directly and the generator handles the ref counting.

5. Spotting leaks

open fds
  ▲
  │        /|      /|      /|        ← saw-tooth: leak cleaned by finalisers
  │      /  |    /  |    /  |
  │    /    |  /    |  /    |
  │  /      |/      |/      |
  └──────────────────────────────► time

  │                     ______ ← plateau at the limit: errors begin
  │                 ___/
  │            ___/
  │       ___/                 ← steady climb: true leak (still referenced)
  └──────────────────────────────► time

6. Try it yourself

1. Run dotnet run on a console app that opens 2,000 files without disposing them and holds them in a list.
2. In another terminal: ls /proc/$(pgrep -f YourApp)/fd | wc -l.
3. Run ulimit -n 256 in the shell before dotnet run and watch the IOException appear.
4. Change the code to using var fs = File.OpenRead(path); and confirm the count stays flat.

// Bad: relies on the finaliser, leaks descriptors under load
public string ReadConfigBad(string path)
{
    var reader = new StreamReader(path);
    return reader.ReadToEnd(); // handle stays open until a GC runs the finaliser
}

// Good: deterministic release
public string ReadConfig(string path)
{
    using var reader = new StreamReader(path);
    return reader.ReadToEnd();
}

// Better for whole files: the framework opens and closes for you
public Task<string> ReadConfigAsync(string path, CancellationToken ct) =>
    File.ReadAllTextAsync(path, ct);

// Wrapping a native handle from a C library safely
using System.Runtime.InteropServices;
using Microsoft.Win32.SafeHandles;

internal sealed class SafeDeviceHandle : SafeHandleZeroOrMinusOneIsInvalid
{
    public SafeDeviceHandle() : base(ownsHandle: true) { }

    protected override bool ReleaseHandle() => NativeMethods.device_close(handle) == 0;
}

internal static partial class NativeMethods
{
    [LibraryImport("mydevice", StringMarshalling = StringMarshalling.Utf8)]
    internal static partial SafeDeviceHandle device_open(string name);

    [LibraryImport("mydevice")]
    internal static partial int device_close(nint handle);

    [LibraryImport("mydevice")]
    internal static partial int device_read(SafeDeviceHandle handle, Span<byte> buffer, int length);
}

# How many descriptors does the process hold, and what are they?
ls -l /proc/$(pgrep -f MyWorker)/fd | wc -l
lsof -p $(pgrep -f MyWorker) | awk '{print $5}' | sort | uniq -c   # by type: REG, IPv4, sock, FIFO
cat /proc/$(pgrep -f MyWorker)/limits | grep -i "open files"