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

Secret File Drop: Uploads with same name don't get renamed to file (1).txt #8291

Closed
tbsbdr opened this issue Jan 26, 2024 · 10 comments
Closed
Assignees
Labels
Priority:p2-high Escalation, on top of current planning, release blocker Type:Bug
Milestone

Comments

@tbsbdr
Copy link

tbsbdr commented Jan 26, 2024

Steps to reproduce

  1. Create a Secret File Drop MyFiledropFolder
  2. Upload file.txt to MyFiledropFolder via the sharing link
  3. Repeat: Again upload file.txt via the sharing link
  4. MyFiledropFolder contains
 ├── file.txt

Expected behavior

  • MyFiledropFolder contains 2 files file.txt and file (1).txt
 ├── file.txt
 └── file (1).txt

Actual behavior

  • MyFiledropFolder contains
 ├── file.txt
@tbsbdr tbsbdr transferred this issue from owncloud/web Jan 26, 2024
@tbsbdr
Copy link
Author

tbsbdr commented Jan 26, 2024

@micbar lets discuss the prio
After discussion with @kulmann

  • collision-check must happen in backend (client does not know about existing files because there are no read permissions)

Open questions:

  • possible to pass a header value to the upload requests that overwrites should be forbidden? Then the backend would not need to check on its own if the upload happened via a secret file drop link.

@micbar micbar added the Priority:p2-high Escalation, on top of current planning, release blocker label Jan 26, 2024
@ScharfViktor
Copy link
Contributor

we have api tests for that which are in the expected failures file with issue tag #1267

@phil-davis
Copy link
Contributor

And that links to discussion in cs3org/reva#2480
Which links to discussion in cs3org/reva#2510
with what I thought was the end decision in comment cs3org/reva#2510 (comment) on Feb 21, 2022 - nearly 2 years ago.

But nothing happened after that.

@phil-davis
Copy link
Contributor

And more related discussion about what the behavior should be in #5074

@butonic
Copy link
Member

butonic commented Feb 1, 2024

@tbsbdr what naming scheme should be used?
0) pm: file.txt, file (1).txt, file (2).txt

  1. oc10 & windows: file.txt, file (2).txt, file (3).txt (humans count the file.txt as 1)
  2. phil: file.txt, file_fs93e.txt, file_pa4io.txt
  3. CERN: {uuid} file.txt
  4. timestamp: file.txt, file (2024-02-01 14:56:54.003Z).txt, file (2024-02-01 14:56:55.004Z).txt

I highly recommend not deviating from what other systems like windows do. Endusers might expect this behavior. Also ... our oc10 tests already expect option 1)

@tbsbdr
Copy link
Author

tbsbdr commented Feb 1, 2024

option 1 like in Windows
file.txt, file (2).txt, file (3).txt

@AlexAndBear
Copy link
Contributor

AlexAndBear commented Feb 5, 2024

@tbsbdr could you check that with the current implementation in web? IHMO we go f, f(1) (you skipped that). Maybe we need to adjust web then

@tbsbdr
Copy link
Author

tbsbdr commented Feb 5, 2024

I would just align it if the effort is < 30 mins as I bet no one will notice it (except for the pain we experience by being aware of that inconsistency)

@dragonchaser
Copy link
Member

@tbsbdr should we close this here and track this on web?

@micbar micbar added this to the Release 5.0.0 milestone Feb 7, 2024
@tbsbdr
Copy link
Author

tbsbdr commented Feb 7, 2024

fixed via #8340

@tbsbdr tbsbdr closed this as completed Feb 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Priority:p2-high Escalation, on top of current planning, release blocker Type:Bug
Projects
Status: Done
Development

No branches or pull requests

7 participants