Fall back to direct cache write if tempfile creation on the same fs fails

[myzhang1029]

Please see #2288 for the discussion.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 97.27626% with 7 lines in your changes missing coverage. Please review.
✅ Project coverage is 74.32%. Comparing base (b81fdbb) to head (3804ba5).

Files with missing lines	Patch %	Lines
src/cache/cache_io.rs	95.51%	7 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2369      +/-   ##
==========================================
+ Coverage   73.58%   74.32%   +0.73%     
==========================================
  Files          70       70              
  Lines       38220    39471    +1251     
==========================================
+ Hits        28125    29337    +1212     
- Misses      10095    10134      +39     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[sylvestre]

would it be possible to add a test to make sure we don't regress in the future?
thanks

[myzhang1029]

@sylvestre
I am not familiar with a similar concept under Windows, so is it fine if I hardcode a test for something under /dev and make this test case cfg(unix)?

[myzhang1029]

Rebased on main and added two tests. Both tests succeed on the branch and fail before the patch.

I am not entirely sure if the use of /dev/fd is portable enough to all the unices that Rust and sccache intend to support. Please feel free to skip that one if not.

[sylvestre]

could you please add high level tests in https://github.com/mozilla/sccache/blob/main/tests/system.rs too ? thanks

like

sccache/tests/system.rs

Line 1825 in 7025295

fn test_sccache_command(preprocessor_cache_mode: bool) {

[myzhang1029]

@sylvestre Sorry for the delayed response. I am planning to test this by adding two functions that are similar to test_basic_compile in system.rs.

One of them should test /dev/null and the other for /dev/stdout (AssertCmd::assert seems to capture stdout already --- better approach maybe?) They would:

1. Compiles a file
2. Repeats the compilation command
3. Check that both commands succeed and that #miss and #hit are both 1.

[myzhang1029]

On a second thought, I have a question:

I think I named the PR a bit too narrow. Maybe like

Fall back to direct cache write if parent directory is not writable

I was think of reframing the PR this way, because this way, we don't have to hardcode /dev anymore. We can instead:

1. run the first compilation command
2. chmod u-w the destination dir
3. run the second (cached) pass

[myzhang1029]

@AJIOB I have pushed the change. Sorry for the delay.

[myzhang1029]

There is an issue with the tests: we use the same INPUT, so the cache stats depend on the previous tests. I feel like it would become a maintenance disaster to hardcode the expected stats into the tests in this case. Would it be acceptable to put a pair of start_local_daemon stop_local_daemon in each test?

[myzhang1029]

CI should work now.

I have relaxed one more error handling: in the case that same-fs file creation fails, we also allow chmod to fail.

[AJIOB]

Hi @myzhang1029 ,

I face with that error
As a result, the OpenSSL Perl incorrectly generates assembly file.

Do you have some plans to actualize the PR?

[myzhang1029]

Hello @AJIOB

Is my understanding correct that this patch would fix that error you mentioned?

Lots has happened in the repo and let me work on this today!

[AJIOB]

I hope it helps.

In the trace mode I have:

[2026-03-11T12:18:02Z DEBUG sccache::compiler::compiler] Found gcc
[2026-03-11T12:18:02Z TRACE sccache::server] Inserting POSSIBLY PROXIED cache map info for "/usr/bin/gcc"
[2026-03-11T12:18:02Z DEBUG sccache::server] check_compiler: Supported compiler
[2026-03-11T12:18:02Z DEBUG sccache::server] parse_arguments: Ok: ["-Wa,-v", "-c", "-o", "/dev/null", "-x", "assembler", "/dev/null"]
[2026-03-11T12:18:02Z DEBUG sccache::compiler::compiler] [null]: get_cached_or_compile: ["-Wa,-v", "-c", "-o", "/dev/null", "-x", "assembler", "/dev/null"]
[2026-03-11T12:18:02Z TRACE sccache::util] Hashed 0 files in 0.000 s
[2026-03-11T12:18:02Z DEBUG sccache::compiler::c] generate_hash_key: Disabling preprocessor cache because assembler language doesn't need C preprocessing
[2026-03-11T12:18:02Z DEBUG sccache::compiler::compiler] [null]: generate_hash_key took 0.000 s
[2026-03-11T12:18:02Z DEBUG sccache::compiler::compiler] [null]: Hash key: 11b765162fadb5068b7bb35ddec6a07e17f458f37cef7c0d884955a66981f15c
[2026-03-11T12:18:02Z TRACE sccache::cache::disk] DiskCache::get(11b765162fadb5068b7bb35ddec6a07e17f458f37cef7c0d884955a66981f15c)
[2026-03-11T12:18:02Z DEBUG sccache::compiler::compiler] [null]: Cache hit in 0.014 s
[2026-03-11T12:18:02Z ERROR sccache::server] ["null"] fatal error: Permission denied (os error 13) at path "/dev/.tmp9gyxnV"
[2026-03-11T12:18:02Z ERROR sccache::server] ["null"] 	Permission denied (os error 13) at path "/dev/.tmp9gyxnV"

[AJIOB]

P.S. Just an easy-to-reproduce test on the latest sccache 0.14.0:

$ gcc -Wa,-v -c -o /dev/null -x assembler /dev/null
GNU assembler version 2.42 (x86_64-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.42
$ sccache gcc -Wa,-v -c -o /dev/null -x assembler /dev/null
sccache: encountered fatal error
sccache: error: Permission denied (os error 13) at path "/dev/.tmpNJtyLa"
sccache: caused by: Permission denied (os error 13) at path "/dev/.tmpNJtyLa"

[AJIOB]

Hi @myzhang1029 ,

Do you have any updates?

[myzhang1029]

Sorry for the delay as my area was hit by some severe weather.

This time is largely just rebasing the code and resolving conflicts, but this version should already fix the openssl building error you mentioned. What is left is to figure out the tests properly.

[AJIOB]

Hi @sylvestre,

Is this PR OK to you?

[myzhang1029]

Moved the unit tests to cache_io.rs since it uses a private interface.
I've moved the integration tests to branch pr2369-tests since I realized that the expected constants (counts) depend on the platform.

Edit: The integration tests have been merged back.

[myzhang1029]

Just gonna rebase onto main to see if the new tests still work :)

[AJIOB]

Hi @drahnr ,

Is it OK for you?

[myzhang1029]

another rebase onto main, mainly for checking compatibility with #2581

[myzhang1029]

I got my hands on a windows machine and it turned out I simplified the NUL mess. Now fixed.

[myzhang1029]

@drahnr The testsuites seem to work on my FreeBSD VM. Could you please have a look? Thanks!

[myzhang1029]

@drahnr @sylvestre Hi Both,

How do you feel about merging this patch?