Skip to content

Conversation

@icewind1991
Copy link
Member

@icewind1991 icewind1991 commented Jun 30, 2025

Since the copy is spiritually a newly created file, the old permissions shouldn't affect it.

Fixes #52779

Signed-off-by: Robin Appelman <robin@icewind.nl>
@icewind1991 icewind1991 added this to the Nextcloud 32 milestone Jun 30, 2025
@icewind1991 icewind1991 requested a review from a team as a code owner June 30, 2025 16:16
@icewind1991 icewind1991 requested review from ArtificialOwl, leftybournes and yemkareems and removed request for a team June 30, 2025 16:16
@icewind1991 icewind1991 added 3. to review Waiting for reviews 2. developing Work in progress and removed 3. to review Waiting for reviews labels Jun 30, 2025
@icewind1991
Copy link
Member Author

Failing tests are due to a check introduced with #41565 needs to be clarified what the correct behavior is.

@vermeeren
Copy link

Is there anything blocking this currently? I also ran into this today and would enjoy seeing it fixed very much!

Cheers

This was referenced Aug 22, 2025
This was referenced Aug 28, 2025
This was referenced Sep 4, 2025
This was referenced Sep 25, 2025
@skjnldsv skjnldsv modified the milestones: Nextcloud 32, Nextcloud 33 Sep 28, 2025
rotdrop added a commit to rotdrop/nextcloud-app-files-archive that referenced this pull request Oct 15, 2025
See

- rotdrop/files_archive#55
- nextcloud/server#53726
- nextcloud/server#53733

Nextcloud up to and including version 32 copies the
read-only-permissions of a read-only source to the target of a copy
operation, even if the destination storage is writable.

This should be fixed upstream, as a workaround a forced scan of the
destination seems to also fix the problem at the cost of performance, of
course.
rotdrop added a commit to rotdrop/nextcloud-app-files-archive that referenced this pull request Oct 15, 2025
See

- #55
- nextcloud/server#53726
- nextcloud/server#53733

Nextcloud up to and including version 32 copies the
read-only-permissions of a read-only source to the target of a copy
operation, even if the destination storage is writable.

This should be fixed upstream, as a workaround a forced scan of the
destination seems to also fix the problem at the cost of performance, of
course.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

2. developing Work in progress

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: Copy file to a dir where Re-Sharing is enable still disallows Re-Sharing

5 participants