-
Notifications
You must be signed in to change notification settings - Fork 669
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
reproducible data loss when file is renamed and virtual file suffix is added at the same time #7001
Comments
Also reproducable with a windows client. Ouch! |
reproducible with Macos client as well , i have just tested it |
Yes, simpler reproduction:
The sync engine sees this as a deletion of test.txt and the creation of an erroneous placeholder file other.txt.owncloud. What's the expected behavior? Renaming test.txt to other.txt on the remote and dehydrating other.txt.owncloud? I expect a similar problem to occur if one renamed test.txt.owncloud to other.txt: test.txt.owncloud would be recreated and a silly other.txt would be uploaded. |
(Issue moved per @ckamm internal comment) |
Reasons: This is complicated to fix. A fix would take a bit and probably not be in time for 2.5.3. Also, a fix in 2.5 would need to be redone against the new discovery code in 2.6, doubling the work. I think moving to 2.6 is acceptable since the feature is experimental. |
Users can rename a file *and* add/remove the vfs suffix at the same time leading to very complex sync actions. This patch doesn't add support for them, but adds tests and makes sure these cases do not cause unintened behavior. The rename will be propagated, but the users's hydrate/dehydrate request will be ignored.
Users can rename a file *and* add/remove the vfs suffix at the same time leading to very complex sync actions. This patch doesn't add support for them, but adds tests and makes sure these cases do not cause unintened behavior. The rename will be propagated, but the users's hydrate/dehydrate request will be ignored.
Users can rename a file *and* add/remove the vfs suffix at the same time leading to very complex sync actions. This patch doesn't add support for them, but adds tests and makes sure these cases do not cause unintened behavior. The rename will be propagated, but the users's hydrate/dehydrate request will be ignored.
Users can rename a file *and* add/remove the vfs suffix at the same time leading to very complex sync actions. This patch doesn't add support for them, but adds tests and makes sure these cases do not cause unintened behavior. The rename will be propagated, but the users's hydrate/dehydrate request will be ignored.
@ckamm unfortunately it's still reproducible with ownCloud-2.6.0.11958.11762-daily20190510.msi |
@lazawan On Windows with cfapi based vfs .owncloud files should have no special behavior at all. What exactly are you seeing? |
@ckamm i added extension .ownCloud to a virtual file (a pdf file in virtual mode with Cloud sign ) and then this file was ignored from client and disappeared from server |
Interesting, looks like .owncloud is in the ignore list? I'll try to reproduce. |
@ckamm i have just checked the ignore list , .ownCloud ist not in the list |
@lazawan I've not been able to reproduce the problem with ownCloud-2.6.0.12048.11850-daily20190530.msi. When I rename to .ownCloud in my wincfapi vfs folder the rename gets propagated to the server. The behavior you describe would happen for ignored files. Could you double check your If it's not there: could you get me some logs? |
macOS 10.14.5, 2.6.0alpha2 (build 12128) Scenario 1
Scenario 2
|
I can reproduce the issue in scenario 2 - which is odd because there's an explicit autotest for it and that passes. |
Previously a checksum computation could be done on a suffix-placeholder file, making discovery believe that no move took place.
Previously a checksum computation could be done on a suffix-placeholder file, making discovery believe that no move took place.
Works as expected on macOS 10.14.6, client 2.6.0beta1 (build 12241) |
Hi there ,
operating system : Ubuntu 18.10; client 2.5.2rc2
i think title says a lot , simply follow the steps to reproduce the data loss :
something.txt.owncloud_virtual
something.pdf.owncloud_virtual
-now rename files to something.owncloud_virutal (please delete the extensions .pdf and .txt )
-files are not existing any more on the server
regards
The text was updated successfully, but these errors were encountered: