cargo clean: error: could not remove build directory

[trevyn]

Problem

cargo clean sometimes fails to remove build directories, but simply re-running it succeeds.

error: could not remove build directory

Caused by:
  failed to remove directory `/Users/e/Documents/GitHub/turbo/target/wasm32-unknown-unknown`

Caused by:
  Directory not empty (os error 66)

Steps

No response

Possible Solution(s)

This seems to use std::fs::remove_dir, perhaps std::fs::remove_dir_all would be a better option?

Notes

No response

Version

cargo 1.67.0-nightly (e027c4b5d 2022-11-25)
release: 1.67.0-nightly
commit-hash: e027c4b5d25af2119b1956fac42863b9b3242744
commit-date: 2022-11-25
host: aarch64-apple-darwin
libgit2: 1.5.0 (sys:0.15.0 vendored)
libcurl: 7.79.1 (sys:0.4.59+curl-7.86.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
os: Mac OS 12.6.1 [64-bit]

[weihanglo]

Thank you for this report.

We need your help to look into this issue. cargo clean generally remove contents first then directories. Maybe something wrong in the assumption of that. If you could provide a reproducible demo, that will help a lot in making the situation clear, and we could also add a new tests based on that.

[arlosi]

After it fails, what files/folders are still remaining in the directory?

[trevyn]

After it fails, what files/folders are still remaining in the directory?

Ah interesting, it's the macOS .DS_Store file. (https://en.wikipedia.org/wiki/.DS_Store)

I'm guessing the OS is re-generating this between the time the directory is emptied and the time the directory itself is removed.

Note that the PR linked above (using remove_dir_all) does solve the problem for me.

[weihanglo]

Perhaps a Finder.app was there and trying to access that directory?
Anyhow, the pull request seems fine with me.

[HamishPoole]

❯ cargo clean
error: could not remove build directory

Caused by:
  failed to remove directory `/Users/hamishpoole/projects/examples/dioxus_various/docsite/target`

Caused by:
  Directory not empty (os error 66)

docsite on  master [!?] is 📦 v0.0.0 via 🦀 v1.68.0 
❮ ls -la /Users/hamishpoole/projects/examples/dioxus_various/docsite/target  

total 16
drwxr-xr-x@  3 hamishpoole  staff    96 May 10 13:47 .
drwxr-xr-x  22 hamishpoole  staff   704 May 10 13:18 ..
-rw-r--r--@  1 hamishpoole  staff  6148 May 10 13:47 .DS_Store


❯ mdls /Users/hamishpoole/projects/examples/dioxus_various/docsite/target/.DS_Store
kMDItemFSContentChangeDate = 2023-05-10 03:47:00 +0000
kMDItemFSCreationDate      = 2023-05-10 03:47:00 +0000  -- 5 minutes ago.
kMDItemFSCreatorCode       = "    "
kMDItemFSFinderFlags       = 16400
kMDItemFSHasCustomIcon     = 0
kMDItemFSInvisible         = 1
kMDItemFSIsExtensionHidden = 1
kMDItemFSIsStationery      = 0
kMDItemFSLabel             = 0
kMDItemFSName              = ".DS_Store"
kMDItemFSNodeCount         = 6148
kMDItemFSOwnerGroupID      = 20
kMDItemFSOwnerUserID       = 501
kMDItemFSSize              = 6148
kMDItemFSTypeCode          = "    "å

Ran into this issue building with Dioxus Rust

Unable to replicate it exactly. When I shifted terminals to the inbuilt MacOS terminal, the issue disappeared. When I reopened CLion, the issue disappeared.

For the life of me, cannot figure out what application called Finder.app to insert a .DS_Store file.

sudo fs_usage -w -f filesys | rg /Users/hamishpoole/projects/examples/dioxus_various/docsite/target

This turned up nothing.