Offline File Deletion on Reconnect (OS Error 10060) - Demand Immediate Fix

This is a report of a **critical, data-destructive bug** in your sync client. I am not here to ask for data recovery—the files are gone. I am here to **demand that you fix this vulnerability immediately** before it causes further data loss for other users.

### 1. The Bug: Client Deletes Offline-Created Files on Reconnection
* **OS**: Windows 11
* **Client**: 0.2.0
* **Steps to Reproduce the Data Loss**:
1. Work offline. Create or modify a file (e.g., `文档.docx`) within the Cloudreve sync folder. The client is offline.
2. The client attempts to sync in the background, fails with a **TCP Connect Error (OS Error 10060)** as shown in the attached screenshot. The file remains locally.
3. **The critical flaw**: When a stable internet connection is restored, instead of syncing the pending file, the client **deletes it from the local filesystem**.

This is not a sync conflict. This is the client **destroying user data** because of a previous network error. The local file, which existed for days, is removed upon reconnection. This behavior is indefensible for any software claiming to be a "sync" tool.

### 2. The Severity: A Fundamental Breach of Trust
The core promise of a sync client is **"first, do no harm" to local data**. Your client is violating this principle. A network error (10060) should never result in local file deletion. This bug demonstrates a catastrophic failure in your error handling and state management logic.

I have lost important work. I do not expect you to recover it. I **do** expect you to treat this with the maximum severity (`Severity: Critical`) and allocate resources to fix it **now**.

### 3. My Demand: An Immediate Code Fix and Transparent Response
1. **Acknowledge this issue publicly** as a critical bug that causes data loss.
2. **Provide a detailed technical explanation** of the flawed logic that causes a network error to trigger a local delete. What is the exact code path?
3. **Commit to a specific timeline** for a hotfix or patch release that resolves this. This is not a feature request; it is a stability and safety patch that must be prioritized.
4. **Update your documentation** to warn users of this risk until a fix is deployed.

Attached is the screenshot of the `os error 10060` from the client log, timestamped just before the file deletion occurred.

This bug erases user data. Fix it.

Related Logs:
```plaintext
2026-05-07T02:11:34.990508Z  INFO ThreadId(74) shellext::custom_state: Getting item properties for XXXXXXXXXXX
2026-05-07T02:11:34.990728Z ERROR ThreadId(74) shellext::custom_state: No metadata found for path XXXXXXXXXXX
```

---

**Additional critical evidence:** The client did not merely delete the files. It has now performed a **chaotic rollback**, reverting my entire sync folder to its state from approximately three days ago (the point of sustained offline work), while inconsistently preserving a small subset of later changes that had synced successfully during brief connectivity. This proves the defect is not a simple deletion error, but a **fundamental failure in the client's state and version reconciliation logic**, placing user data in an arbitrary, inconsistent, and irrecoverable state. This demands immediate technical investigation and a fix.

Begin with the Windows 11 offline/reconnect reproduction for client 0.2.0 and inspect the shelllext::custom_state log path around OS error 10060 and the reported missing metadata. Done means reconnecting preserves offline-created files, avoids arbitrary rollback or deletion, and retains successfully synced changes; the payload names no source file or test to run.

Written by the indexing model from the issue text.