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:
- Work offline. Create or modify a file (e.g.,
文档.docx) within the Cloudreve sync folder. The client is offline.
- 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.
- 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
- Acknowledge this issue publicly as a critical bug that causes data loss.
- 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?
- 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.
- 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:
�[2m2026-05-07T02:11:34.990508Z�[0m �[32m INFO�[0m ThreadId(74) �[2mshellext::custom_state�[0m�[2m:�[0m Getting item properties for XXXXXXXXXXX
�[2m2026-05-07T02:11:34.990728Z�[0m �[31mERROR�[0m ThreadId(74) �[2mshellext::custom_state�[0m�[2m:�[0m 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.
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
文档.docx) within the Cloudreve sync folder. The client is offline.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
Attached is the screenshot of the
os error 10060from the client log, timestamped just before the file deletion occurred.This bug erases user data. Fix it.
Related Logs:
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.