Skip to content
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

Closed
lazawan opened this issue Jan 24, 2019 · 14 comments
Assignees
Labels
feature:vfs native virtual files and placeholder implementation p2-high Escalation, on top of current planning, release blocker ReadyToTest QA, please validate the fix/enhancement type:bug
Milestone

Comments

@lazawan
Copy link

lazawan commented Jan 24, 2019

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 :

  • enable virtual-files Feature
  • delete all files in sync-folder then a message pops up ,please select keep files
  • let's suppose we have 2 files with following extensions :
    something.txt.owncloud_virtual
    something.pdf.owncloud_virtual
  • please download the files (listed above) over owncloud-menu
  • files are now so : something.pdf and something.txt
    -now rename files to something.owncloud_virutal (please delete the extensions .pdf and .txt )
  • force sync
    -files are not existing any more on the server

regards

@jnweiger
Copy link
Contributor

Also reproducable with a windows client. Ouch!

@ckamm ckamm added this to the 2.5.x-next milestone Jan 24, 2019
@ckamm ckamm added type:bug feature:vfs native virtual files and placeholder implementation labels Jan 24, 2019
@lazawan
Copy link
Author

lazawan commented Jan 25, 2019

reproducible with Macos client as well , i have just tested it

@ckamm
Copy link
Contributor

ckamm commented Jan 28, 2019

Yes, simpler reproduction:

  • have test.txt synced
  • rename to other.txt.owncloud
    test.txt will be deleted and other.txt.owncloud will be ignored.

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.

@guruz guruz modified the milestones: 2.5.3, 2.5.x-next Jan 31, 2019
@guruz
Copy link
Contributor

guruz commented Jan 31, 2019

(Issue moved per @ckamm internal comment)

@ckamm ckamm modified the milestones: 2.5.x-next, 2.6.0 Jan 31, 2019
@ckamm
Copy link
Contributor

ckamm commented Jan 31, 2019

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.

@ckamm ckamm changed the title reproducible data loss when one tries to rename files in virtual files modus on client 2.5.2rc2 reproducible data loss when file is renamed and virtual file suffix is added at the same time Mar 7, 2019
ckamm added a commit that referenced this issue Mar 20, 2019
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 added a commit that referenced this issue Mar 20, 2019
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 added a commit that referenced this issue Mar 21, 2019
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 added a commit that referenced this issue Mar 21, 2019
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 ckamm added the ReadyToTest QA, please validate the fix/enhancement label Mar 21, 2019
@lazawan
Copy link
Author

lazawan commented May 10, 2019

@ckamm unfortunately it's still reproducible with ownCloud-2.6.0.11958.11762-daily20190510.msi

Screenshot from 2019-05-10 14-16-46

@ckamm
Copy link
Contributor

ckamm commented May 16, 2019

@lazawan On Windows with cfapi based vfs .owncloud files should have no special behavior at all. What exactly are you seeing?

@lazawan
Copy link
Author

lazawan commented May 16, 2019

@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

@ckamm
Copy link
Contributor

ckamm commented May 20, 2019

Interesting, looks like .owncloud is in the ignore list? I'll try to reproduce.

@lazawan
Copy link
Author

lazawan commented May 20, 2019

@ckamm i have just checked the ignore list , .ownCloud ist not in the list
and i could reproduce it again :'(

@ckamm ckamm added p2-high Escalation, on top of current planning, release blocker and removed ReadyToTest QA, please validate the fix/enhancement labels May 28, 2019
@ckamm
Copy link
Contributor

ckamm commented Jun 4, 2019

@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 C:\Users\$USER\AppData\Roaming\ownCloud\sync-exclude.lst? Some in-between test versions when we started working on vfs added the .ownCloud extension there.

If it's not there: could you get me some logs?

@ckamm ckamm added the ReadyToTest QA, please validate the fix/enhancement label Jun 4, 2019
@HanaGemela
Copy link
Contributor

HanaGemela commented Jul 19, 2019

macOS 10.14.5, 2.6.0alpha2 (build 12128)

Scenario 1

  1. have test.txt synced
  2. rename to other.txt.owncloud
    Actual result: This keeps only one file -> OK

Scenario 2

  1. have virtual file test.txt.owncloud
  2. rename to other.txt
    Actual result: This keeps both copies -> Not OK

@HanaGemela HanaGemela removed the ReadyToTest QA, please validate the fix/enhancement label Jul 19, 2019
@ckamm
Copy link
Contributor

ckamm commented Jul 24, 2019

I can reproduce the issue in scenario 2 - which is odd because there's an explicit autotest for it and that passes.

ckamm added a commit that referenced this issue Jul 24, 2019
Previously a checksum computation could be done on a suffix-placeholder
file, making discovery believe that no move took place.
ckamm added a commit that referenced this issue Jul 24, 2019
Previously a checksum computation could be done on a suffix-placeholder
file, making discovery believe that no move took place.
@ckamm ckamm added ReadyToTest QA, please validate the fix/enhancement and removed PR available labels Jul 24, 2019
@HanaGemela
Copy link
Contributor

Works as expected on macOS 10.14.6, client 2.6.0beta1 (build 12241)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature:vfs native virtual files and placeholder implementation p2-high Escalation, on top of current planning, release blocker ReadyToTest QA, please validate the fix/enhancement type:bug
Projects
None yet
Development

No branches or pull requests

5 participants