client
client copied to clipboard
Self-deleting files when using VFS
Pre-submission Checks
- [X] I checked for similar issues, but could not find any. I also checked the closed issues. I could not contribute additional information to any existing issue.
- [X] I will take the time to fill in all the required fields. I know that the bug report may be dismissed otherwise due to lack of information.
Describe the bug
Files are periodically self-deleted. The files themselves are deleted, and all folders (directories), including nested ones, remain empty. Two users had this behavior, and one of the users had it happen twice.
Expected behavior
I expect that the files should not be deleted themselves.
Steps to reproduce the issue
I have no idea how to reproduce this
Screenshots
No response
Logs
The owncloud.log file is empty, there are no entries in it.
Desktop Client 4.2.0.11670 2023-11-07T14:00:02Z | Documents/Tasks/Den/TaskList.doc | SyncInstruction(CSYNC_INSTRUCTION_REMOVE) | OCC::SyncFileItem::Up | | 1484141074 | 2321c4ed1d6d1dcdf1d03ebe599fe061 | 47104 | 00280366oc8yx9936pg8 | OCC::SyncFileItem::Success | | 204 | 47104 | 1484141074 | 6af60d69-2d7c-472e-aef4-3383eba5a74a |
Web Server ... - Den [07/Nov/2023:17:00:02 +0300] “DELETE /remote.php/dav/files/Den/Documents/Tasks/Den/TaskList.doc HTTP/1.1” 204 0 “-” “Mozilla/5.0 (Windows) mirall/4.2.0.11670 (ownCloud, windows-10.0.18362 ClientArchitecture: x86_64 OsArchitecture: x86_64)”
Client version number
4.2.0.11670
Desktop environment (Linux only)
Windows 10.0.18362 Pro
Client package version and origin (Linux only)
No response
Installation path (Windows only)
No response
Server information
Server: Ubuntu Server Owncloud server: 10.13.2 PHP: 7.4.33 PHP APCu: 5.1.22 Redis: 5.3.7 Apache2: 2.7.4 Mysql: 5.7.26
Additional context
I'm afraid I won't be able to find more information, since the spontaneous deletion was a long time ago, and I noticed the problem only today.
Apparently the client detected a local deletion and propagated that to the server. Are there previous mentions of that deleted file in the log?
Hi! Unfortunately, logging was not enabled on my client. therefore, all the information that I own is located in the ".owncloudsync" file. In this file I see:
#=#=#=#=# Propagation starts 2023-12-06T09:56:03Z (last step: 1292 msec , total: 1292 msec)
2613 lines of this type
| CSyncEnums::CSYNC_INSTRUCTION_REMOVE | OCC::SyncFileItem::Up | | 1684491555 | a97b058aadfb4c908d29cbce90e00969 | 11889 | 01756054oc8yx9936pg8 | OCC::SyncFileItem::Success | | 204 | 11889 | 1684491555 | 8ee844e7-c176-4425-a816-4a048f5d2667 |
#=#=#=# Syncrun finished 2023-12-06T09:59:56Z (last step: 232163 msec , total: 233455 msec)
Indeed, 2,613 files were deleted. Once again, I want to draw your attention, only files were deleted, all folders (directories) where the deleted files were located remained, only they are now empty.
The above information was taken from another user's computer! Who had the same situation!
It turns out that this situation has already occurred for two users. The client versions, windows versions, are identical. the clients were connected to the same server.
I just had this problem again.... a large number of files were deleted. Now I will collect all the logs and post all the information here.
@TheKaban 5.2.1 is the current stable and supported version.
@michaelstingl
username [24/Jan/2024:18:10:13 +0300] "DELETE /remote.php/dav/files/username/filename.pdf HTTP/1.1" 204 0 "-" "Mozilla/5.0 (Windows) mirall/5.2.1.13040 (ownCloud, windows-10.0.18362 ClientArchitecture: x86_64 OsArchitecture: x86_64)"
I changed what is in bold due to confidentiality.
Please note that this line indicates the version of the client and operating system. As you can see, this version is the current stable version of the client.
Since this just happened, I can provide all the necessary information to solve this problem.
Let me remind you that many files were spontaneously deleted, while the folders (directories) where they were located remained, but became empty.
I would also like to note that this is not the first time a similar situation has happened to different users. The first problems were noticed after switching to version 4.2.0
This is a screenshot from the web interface of a small part of the deleted files
I created an anonymous upload link for 5.2.1 desktop client debug logs:
- https://cloud.owncloud.com/s/GxWQb7B1IgwW4GG
Happy to investigate what happened there… 🤞
This is the private link for the ownCloud team to access:
- https://cloud.owncloud.com/f/6164900
@michaelstingl I added web server logs and owncloud server logs. Tomorrow I will be able to add the client log, since the client computer is far from me.
Looking through the logs, I noticed that at first there was a massive file change, and only after that the deletion began.
@michaelstingl I added web server logs and owncloud server logs. Tomorrow I will be able to add the client log, since the client computer is far from me.
This is the desktop client repo. Desktop team is best in reading desktop client debug logs… 😉
@michaelstingl Hello! I just downloaded the client log file.
No desktop client debug log uploaded yet. Here you can find more information:
- https://doc.owncloud.com/desktop/5.2/appendices/troubleshooting.html#log-files
@michaelstingl Logging was disabled in the client, which is why this log file does not exist. I just enabled logging on the client.
Same Problem here.. actually maybe user problems. I dont know.
On Owncloud 9.4, -4- Times last year Users Windows Client (Last Version) start to deleting all available File that is shared with them. (Document Database, 25000 Files)
Yesterday i update Owncloud to latest Release, so we wait.
The Users said the same "Used Owncloud like every Day, and Shutdown Windows".
Every User has activated "activate the Start on Login" to have Sync the whole day.
P.S. The Client after the last Deleting Action after i give him the Login back started to print endless Activity Logs "Creating Virtual File".
This issue was marked stale because it has been open for 30 days with no activity. Remove the stale label or comment or this will be closed in 7 days.
The issue was marked as stale for 7 days and closed automatically.