This will avoid a rare-but-regular crash in low-memory situations.
Note that this is a workaround: In 2.6 this code should be adjusted to
not read a full file chunk into memory immediately and instead load more
data on demand.
When a file is tagged ItemTypeVirtualFileDownload in the database the
REMOTE pass in csync_update would not find the matching item in the
database. It worked anyway since the rename detection finds it, sees
the type tag and does the right thing. But the logging was confusing.
This change allows the pass to find the matching entry in the database
and proceed to the "db-entry-found" case without going through rename
detection.
If user A shares something with user B and allows resharing but removes
some other permission then user B should be able to share the item or
any of its contents with user C and the new share permissions should
automatically be <= the permissions of the original share.
Currently this works correctly when resharing the original item but
fails for any subitem, preventing the reshare entirely.
With this patch the reshare will always be created with appropriately
limited permissions.
Previously the pin states of deleted files stayed in the 'flags'
database and could be inadvertently reused when a new file with the same
name appeared. Now they are deleted.
To make this work right, the meaning of the 'path' column in the 'flags'
table was changed: Previously it never had the .owncloud file suffix.
Now it's the same as in metadata.path.
This takes the safe parts from #7274 for inclusion in 2.6. The more
elaborate database schema changes (why use 'path' the join the two
tables in the first place?) shall go into master.
Previously RequestEtagJob did return the etag verbatim (including extra
quotes) while the db had the parsed form. That caused the etag
comparison during discovery move detection to always fail. The test
didn't catch it because the etags there didn't have quotes.
Now:
- RequestEtagJob will parse the etag, leading to a consistent format
- Tests have etags with quotes, detecting the problem
- Close the UploadDevice to close the QFile after the PUT job is done.
This allows winvfs to get an oplock on the file later.
- Don't rely on QFile::fileName() to be valid after
openAndSeekFileSharedRead() was called. The way it is openend on
Windows makes it have an empty filename.
If one adds a new file to an online-only folder the previous behavior
was to upload the file in one sync and dehydrate it in the next. Now
these new files get set to Unspecified pin state, making them retain
their data.
Fixes the "Copy public link to clipboard" context menu action for newer
servers.
Previously the server would fill the expiration date for us, since
version 10.2.0 it reports an error. To workaround that the action now
always sends an expiration date if default expiration is enabled in
the settings.
For #7245
Currently it's confusing because without user changes "Sync None" and
"Apply manual changes" have the same meaning. Now the "Apply" action
only becomes available if changes were made.
For #7230
