# Surprising behaviour while working with the filesystem

**URL:** <https://ziggit.dev/t/surprising-behaviour-while-working-with-the-filesystem/9351>\
**Category:** Explain\
**Created:** [March 30, 2025, 1:46am UTC](https://ziggit.dev/t/surprising-behaviour-while-working-with-the-filesystem/9351 "2025-03-30T01:46:19Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![KilianHanich](https://ziggit.dev/user_avatar/ziggit.dev/kilianhanich/32/8254_2.png) [@KilianHanich](https://ziggit.dev/u/KilianHanich)\
**Post date:** [March 30, 2025, 1:46am UTC](https://ziggit.dev/t/surprising-behaviour-while-working-with-the-filesystem/9351/1 "2025-03-30T01:46:19Z")

</div>

Hello,

I don’t think this is particular about Zig, but I have found a quite peculiar behaviour of the following program on at least my system (Fedora 41):

```zig
const std = @import("std");

const name = "testfile";

pub fn main() !void {
    var original = try std.fs.cwd().createFile(name, .{.read = true});
    defer {
        std.fs.cwd().deleteFile(name) catch |err| std.debug.print("delete failed: {}\n", .{err});
        original.close();
    }

    const pid = try std.posix.fork();
    if (pid != 0) {
        std.debug.print("child exited with: {}\n", .{std.posix.waitpid(pid, 0).status});
        var buf = [_]u8{0} ** 50;
        const amount = try original.readAll(&buf);
        std.debug.print("{s}\n", .{buf[0..amount]});
        _ = std.io.getStdIn().reader().readByte() catch {};
    } else {
        var buf = [_]u8{0} ** 50;
        const path = try std.fmt.bufPrint(&buf, "/dev/fd/{}", .{original.handle});
        var new = try std.fs.openFileAbsolute(path, .{.mode = .write_only});
        defer new.close();
        try new.writer().print("Hello from {}\n", .{std.os.linux.getpid()});
    }
}

```

The surprising behaviour happens when I comment out line 8. When it’s **not** commented out, the file isn’t seen on the filesystem while the program waits in line 18, but if it’s commented out, the file is actually seeable. I also only get the complaint of trying to delete it if it’s not commented out.

Does somebody have an idea why this might be?

---

<div class="post-metadata">

**Author:** ![squeek502](https://ziggit.dev/user_avatar/ziggit.dev/squeek502/32/409_2.png) [@squeek502](https://ziggit.dev/u/squeek502)\
**Post date:** [March 30, 2025, 2:06am UTC](https://ziggit.dev/t/surprising-behaviour-while-working-with-the-filesystem/9351/2 "2025-03-30T02:06:47Z")

</div>

Won’t the `defer` with the `deleteFile` run when the child process finishes and therefore the file will be deleted after `waitpid` returns?

---

<div class="post-metadata">

**Author:** ![Eisenhauer](https://ziggit.dev/letter_avatar_proxy/v4/letter/e/76d3ee/32.png) [@Eisenhauer](https://ziggit.dev/u/Eisenhauer)\
**Post date:** [March 30, 2025, 8:34am UTC](https://ziggit.dev/t/surprising-behaviour-while-working-with-the-filesystem/9351/3 "2025-03-30T08:34:16Z")

</div>

You have `defer` of `deleteFile` in scope before starting the child process. If `fork` succeeds, then you have two processes executing the deferred `deleteFile` at their ends of `main`.

As @squeek502 already stated, `waitpid` then orders the two processes, such that child will finish first and therefore delete the file.

The parent process can still read that file, since it had it already open. Linux actually deletes files only after the last process having them open closes them. Nontheless, file deletions remove them immediately from directory listings. So you can’t easily see that file despite the parent process having it still open for reading.

---

<div class="post-metadata">

**Author:** ![KilianHanich](https://ziggit.dev/user_avatar/ziggit.dev/kilianhanich/32/8254_2.png) [@KilianHanich](https://ziggit.dev/u/KilianHanich)\
**Post date:** [March 30, 2025, 12:13pm UTC](https://ziggit.dev/t/surprising-behaviour-while-working-with-the-filesystem/9351/4 "2025-03-30T12:13:56Z")

</div>

Yeah ok, fair enough, I haven’t thought of that.

I should maybe stop late night coding after working for a full day…
