Sergey Bugaev

> Neither the two recursive wipe checks for sym-links I don't know what you're talking about https://github.com/darlinghq/darling/blob/fa5348c8a9b338746b91a53a801343a8d046a66d/src/startup/darling.c#L933-L939 And you're yet to demonstrate that your data being wiped was actually caused...

This function uses `readdir()`, not "stdio routines". `readdir()` reads directory entries; it sets `DT_LNK` in `d_type` for symlinks, and `DT_DIR` only for actual directories.

`opendir()` doesn't check if the path is a symlink, why would it. That means, if the whole directory being wiped (ex. `$DPREFIX/var/tmp`) is a symlink, it's gonna follow that one...

> `/var/run` is symlink to `/run` But is `$DPREFIX/var/run` a symlink to anything? ([No, it isn't](https://github.com/darlinghq/darling/blob/fa5348c8a9b338746b91a53a801343a8d046a66d/src/startup/darling.c#L1069)). Wiping host's `/var/run` indeed would be disastrous, but we're not doing that. > instead...

So I take it you're able to reproduce files under `/run/media/username/` getting deleted around the same time you run Darling? If so, that's great news! Please use `strace` to find...

Let me ask you directly and unambiguously: **have you reproduced this**? If you have, please attach `strace` logs (instructions above). You could also add some explicit logging to the code...

I want to react to what happened yesterday in https://github.com/darlinghq/darling/issues/1006. First of all, thank you everyone for supporting us, it hasn't been easy to have to play the bad guy...

> Okay, I did a bit more research; yes, `/var/run` (and consequently `/run`) is absolutely meant to be cleared. `/var/run` is expected to be clean on boot-up — and on...

It's APFS, actually

- [x] xpc_data_get_bytes - [x] xpc_equal - [x] xpc_fd_create - [x] xpc_array_dup_fd - [ ] xpc_array_set_fd - [ ] xpc_array_get_connection - [x] xpc_array_set_connection - [x] xpc_connection_cancel - [x] xpc_connection_get_name -...