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

Conflict between file and folder is not handled #6312

Closed
ckamm opened this issue Jan 18, 2018 · 3 comments
Closed

Conflict between file and folder is not handled #6312

ckamm opened this issue Jan 18, 2018 · 3 comments
Assignees
Labels
ReadyToTest QA, please validate the fix/enhancement type:bug
Milestone

Comments

@ckamm
Copy link
Contributor

ckamm commented Jan 18, 2018

Basic case:

  • Add a file "foo" locally
  • Add a folder "foo" remotely, with some files inside
  • Start the sync

The sync will not complete successfully. The same happens if the folder is local and the file is remote. Or if what used to be a file becomes a directory on one end while the file changes on the other end.

What should happen is the usual conflict behavior: The local item gets renamed and the remote item gets downloaded.

I have already started to work on this issue.

@ckamm ckamm added the type:bug label Jan 18, 2018
@ckamm ckamm added this to the 2.4.1 milestone Jan 18, 2018
@ckamm ckamm self-assigned this Jan 18, 2018
@ckamm ckamm changed the title Conflicts between files and folder not handled Conflicts between file and folder is not handled Jan 18, 2018
ckamm added a commit that referenced this issue Jan 18, 2018
Previously conflicts with a different type on both ends lead to sync
errors. Now they are handled in the expected way: the local item gets
renamed and the remote item gets propagated downwards.

This also adds a unittest for the TYPE_CHANGE case. That one looks like
parts of it might be unified with CONFLICT cases.
@ckamm ckamm modified the milestones: 2.4.1, 2.5.0 Jan 18, 2018
@ckamm ckamm changed the title Conflicts between file and folder is not handled Conflict between file and folder is not handled Jan 18, 2018
ckamm added a commit that referenced this issue Jan 19, 2018
Previously conflicts with a different type on both ends lead to sync
errors. Now they are handled in the expected way: the local item gets
renamed and the remote item gets propagated downwards.

This also adds a unittest for the TYPE_CHANGE case. That one looks like
parts of it might be unified with CONFLICT cases.
ckamm added a commit that referenced this issue Jan 19, 2018
Previously conflicts with a different type on both ends lead to sync
errors. Now they are handled in the expected way: the local item gets
renamed and the remote item gets propagated downwards.

This also adds a unittest for the TYPE_CHANGE case. That one looks like
parts of it might be unified with CONFLICT cases.
@ckamm ckamm added the ReadyToTest QA, please validate the fix/enhancement label Jan 19, 2018
ckamm added a commit that referenced this issue Jan 24, 2018
Previously conflicts with a different type on both ends lead to sync
errors. Now they are handled in the expected way: the local item gets
renamed and the remote item gets propagated downwards.
@SamuAlfageme
Copy link
Contributor

SamuAlfageme commented Mar 13, 2018

Hmm... while I'm testing this /me wonders if this would be a nice way to solve cash-clashes on the client (things like #5870 (comment) should get better with this same logic).

Using conflicts could be a way (not sure if good or not) to solve part of the neverending story: #1348. What'cha think @ckamm?

@ckamm
Copy link
Contributor Author

ckamm commented Mar 15, 2018

@SamuAlfageme Making case clashes conflicts creates the following problem:

  • Linux user: uploads foo.txt and Foo.txt. Syncs and updates them, all is good.
  • Windows user starts syncing, gets foo.txt and Foo_case_clash_with_foo.txt. That doesn't make sense, foo and Foo are entirely unrelated.

It would probably be ok and better than the current error in cases where the clash is between a local and a remote file, and there are no clashing files on the remote.

@SamuAlfageme
Copy link
Contributor

Fixed 🎉 - great catch @ckamm!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ReadyToTest QA, please validate the fix/enhancement type:bug
Projects
None yet
Development

No branches or pull requests

2 participants