| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
The important thing is that, similar to the web link share creation
flow, the share properties can be set before creation is done. This
allows better handling of error conditions. One such condition is the
password policy app restricting valid expire dates.
See owncloud/enterprise#3271
|
|
To do this, introduce AllDehydrated availability and rename
SomeDehydrated to Mixed - it now guarantees there are also hydrated
items.
|
|
Saying "Currently available locally" sounds more like an indicator than
"Availably locally" does. Centralizing translations avoids consistency
issues between shell context menus and sync folder context menu.
|
|
|
|
For https://github.com/owncloud/enterprise/issues/3257
(cherry picked from commit 076d9fb7f897f658af4894a4517786d8c49144a8)
|
|
QStringRef::operator[] was introduced in 5.7. QStringRef::at() is
equivalent.
|
|
|
|
|
|
The db-close operation is likely a leftover from when the SyncEngine
owned its own db connection and serves no purpose anymore.
Closing the db causes the removal of the temporary wal and shm files.
These files are recreated when the db is opened again, which happens
almost immediately.
This is a problem for winvfs because the delete-recreate step wipes the
exclusion state on these files just after the sync is done. That meant
that the db temporaries permanently had a "needs sync" icon marker shown
in the explorer.
Avoiding reopening the db also reduces the number of log messages per
sync.
|
|
According to the documentation DELETE+NORMAL isn't safe from corruption
on older file systems.
|
|
Previously one would need to wait for the next sync run to create the
first log file.
|
|
|
|
For https://github.com/owncloud/enterprise/issues/3257
|
|
|
|
Previously the property wasn't queried, meaning the fingerprint logic
couldn't get triggered.
|
|
Previously these result codes during remote discovery of the sync root
would not cause an error and the discovery would get stuck.
Also extends RemoteDiscovery tests to check for errors on the root item.
|
|
Previously if one set the instruction to ERROR while forgetting to set
an error status, it'd propagate as FileIgnored. Now the default is
NormalError for INSTRUCTION_ERROR and FileIgnored for
INSTRUCTION_IGNORE.
|
|
|
|
|
|
|
|
The idea is that the user's question is "is this folder's data available
offline?" and not "does this folder have AlwaysLocal pin state?".
The the answers to the two questions can differ: an always-local
folder can have subitems that are not always-local and are dehydrated.
The new availability enum intends to describe the answer to the user's
actual question and can be derived from pin states. If pin states aren't
stored in the database the way of calculating availability will depend
on the vfs plugin.
|
|
The pin state is a per-item attribute that has an effect on _type:
AlwaysLocal dehydrated files will be marked for hydration and OnlineOnly
hydrated files will be marked for dehydration.
Where exactly this effect materializes depends on how the pin states are
stored. If they're stored in the db (suffix) the dbEntry._type is
changed during the discovery.
If the pin state is stored in the filesystem, the localEntry._type must
be adjusted by the plugin's stat callback.
This patch makes pin states behave more consistently between plugins.
Previously with suffix-vfs pin states only had an effect on new remote
files. Now the effect of pinning or unpinning files or directories is as
documented and similar to other plugins.
|
|
|
|
It's still not synced in any way later.
|
|
1. The _firstJob is usually deleted by the time the PropagateDirectory
finishes. (deleteLater() is called early)
2. The PropagateDirectory::_item and PropagateRemoteMkdir::_item point
to the same SyncFileItem anyway. This code is a leftover from when
each job had its own instance.
|
|
This has two positive effects:
- We can put the error on the particular file that has missing data
- We can sync all other files
|
|
Previously removing the vfs suffix of a file always triggered a
conflict. Now it may just cause a file download.
This was done because users expected symmetry in the rename actions and
renaming foo -> foo.owncloud already triggers the "make the file
virtual" action. Now foo.owncloud -> foo triggers the "download the
contents" action.
|
|
Moves a bunch of env var reading from Folder into SyncOptions.
|
|
|
|
Previously it'd be NEW(ItemTypeFile), but now it has changed to be
SYNC(ItemTypeVirtualFileDownload) which allows better classification.
|
|
These files may very well just be new virtual files that were explicitly
*not* downloaded.
|
|
It's possible that the rename target was in the local discovery list.
|
|
destination() now consistently points to the file after the successful
sync operation. _file might be the place the item was moved from.
|
|
There was a bunch of inconsistency around whether _file was set to
_renameTarget or not. This is now never done, passing on more
information.
|
|
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.
|
|
This was not required with 2.5 because a size of 0 was ignorted when comparing
size by the csync updater, to be compatible with very old version of the database.
But the we discovery will still think the file is changed if the database contains
a size of 0
|
|
Implements https://github.com/owncloud/core/pull/31851
|
|
|
|
|
|
When the user typed "x:" where the drive x didn't exist, the validation
function would loop forever. Now it shows a "path doesn't exist" error.
|
|
|
|
It seems that sometimes the tray implementation isn't ready on system
startup. Retrying later seems to not help. Delaying the start of the
client is the workaround that people have reported as effective.
|
|
|
|
It seems that sometimes the tray implementation isn't ready on system
startup. Retrying later seems to not help. Delaying the start of the
client is the workaround that people have reported as effective.
|
|
|
|
It still reads and writes the old format too, but all newly stored
client certs will be in the new form.
For #6776 because Windows limits credential data to 512 bytes in older
versions.
|
