sync: build for wasm by oech3 · Pull Request #14769 · uutils/coreutils

oech3 · 2026-09-21T04:55:54Z

Syncing a file seems possible on wasip at least for.

github-actions · 2026-09-21T05:47:40Z

GNU testsuite comparison:

Skipping an intermittent issue tests/date/resolution (passes in this run but fails in the 'main' branch)

oech3 · 2026-09-22T05:38:19Z

It seems std::fs::File::sync_fata is fdatasync. Should we drop rustix::fs::fdatasync?

oech3 · 2026-09-22T08:30:11Z

Permission denied on Windows...

codspeed · 2026-09-23T01:23:32Z

Merging this PR will improve performance by 39.29%

⚠️

118 benchmarks spent significant time in system calls

System calls cannot be consistently instrumented, so they are not included in the measure, which understates the real cost. Please switch to the Walltime instrument to accurately measure system calls.

Measurement and system calls

du_wide_tree[(5000, 500)]

cksum_sysv

cksum_multiple_files

cksum_crc32b

factor_large_u64_prime

dd_copy_partial

factor_multiple_u64s[2]

sort_long_common_prefix_utf8_locale

merge_pre_sorted_files_utf8_locale

tr_single_char_replace

…and 108 more

ℹ️ 1 benchmark has no flame graph

The flamegraph could not be generated because too much time was spent in runtime internals, making the visualization not useful for performance analysis.

sort_dictionary_order[500000]

⚡ 3 improved benchmarks
✅ 398 untouched benchmarks
⏩ 54 skipped benchmarks¹

Performance Changes

	Mode	Benchmark	`BASE`	`HEAD`	Efficiency
⚡	Simulation	`three_39_bit_primes`	591.3 ms	264 ms	×2.2
⚡	Simulation	`five_38_bit_primes`	2.1 s	1.9 s	+11.1%
⚡	Simulation	`thirteen_39_bit_primes`	9.6 s	8.9 s	+8.58%

Tip

Curious why performance improved? Comment @codspeedbot explain why performance improved on this PR, or directly use the CodSpeed MCP with your agent.

_{Comparing oech3:sync-wasi (3488fc4) with main (8b27533)²}

54 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩
No successful run was found on main (a26a332) during the generation of this report, so 8b27533 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

oech3 · 2026-09-28T15:21:32Z

OK to merge this? I'd like to port this for simpler workspace even feature is very limited.

eduardomourar · 2026-10-09T16:06:34Z

+#[cfg(not(any(target_os = "linux", target_os = "android", windows)))]
+fn do_sync_with_regular_file<F>(files: &[String], op: F) -> UResult<()>
+where
+    F: Fn(std::fs::File) -> std::io::Result<()>,
+{
+    use uucore::error::FromIo;
+    for path in files {
+        let mut f = std::fs::OpenOptions::new();
+        f.read(true);
+        // FIXME: sync_data() fails with permission denied even f.write(true) is used on Windows
+        #[cfg(windows)]
+        f.write(true);
+        op(f.open(path)?)
+            .map_err_context(|| translate!("sync-error-syncing-file", "file" => path.quote()))?;
+    }
+    Ok(())
 }


Before this PR, syncfs/fdatasync on macOS/BSD/wasm were not compiled at all, so sync -f/sync -d on those targets was a silent no-op. The existing Linux/Android platform::open_and_reset_nonblock deliberately opens with O_NONBLOCK and resets it, specifically to avoid hanging on FIFOs. The new fallback in do_sync_with_regular_file does a plain std::fs::OpenOptions::open() with no non-blocking handling, so sync -f /path/to/fifo on macOS/BSD/wasm can now hang indefinitely instead of being a no-op.

Do I just need to set O_NONBLOCK?

eduardomourar · 2026-10-09T16:09:27Z

+        // FIXME: sync_data() fails with permission denied even f.write(true) is used on Windows
+        #[cfg(windows)]


I believe there is an error in this line as this check is never compiled to Windows.

But I saw CI's failure.

Probably before it was gated to not Windows.

Even if the test is disabled, user see the error if the cfg was removed. Is it acceptible?

oech3 · 2026-10-09T18:21:27Z

@eduardomourar I'm fine with this PR was replaced with your one if you have knowledge more than me.
This PR does not more than making *.wasm compilable.

eduardomourar · 2026-10-09T19:19:25Z

@eduardomourar I'm fine with this PR was replaced with your one if you have knowledge more than me. This PR does not more than making *.wasm compilable.

I don't want to hijack your PR. I am just reviewing it and helping us improve the code a little bit.

oech3 · 2026-10-25T05:37:09Z

I'd like to split this PR e.g. #15733

oech3 · 2026-10-25T16:31:20Z

Oh wait! Does wasip* support NINBLOCK? I was too early to close this PR.