mirrors/nextcloud-desktop
1
0
Fork 0
mirror of https://github.com/nextcloud/desktop.git synced 2024-10-28 07:54:49 +03:00
Code Issues Projects Releases Packages Wiki Activity
nextcloud-desktop/src/libsync/syncfilestatustracker.cpp

301 lines
13 KiB
C++
Raw Normal View History

Move the SocketApi business logic to a libsync SyncFileStatusTracker class This will allow testing this code and avoid going through too many layers to get notified and a file status changed.
2016-03-17 14:26:44 +03:00
/*
* Copyright (C) by Klaas Freitag <freitag@owncloud.com>
Refactor the overlay icon logic to show errors as a warning for parent folders #3634 This also remove all smartness from the SocketApi about the status of a file and solely use info from the current and last sync. This simplifies the logic a lot and prevents any discrepancy between the status shown in the activity log and the one displayed on the overlay icon of a file. The main benefit of the additional simplicity is that we are able to push all new status of a file reliably (including warnings for parent folders) to properly update the icon on overlay implementations that don't allow us invalidating the status cache, like on OS X. Both errors and warning from the last sync are now kept in a set, which is used to also affect parent folders of an error. To make sure that errors don't become warning icons on a second sync, SyncFileItem::_hasBlacklistEntry is also interpreted as an error. This also renames StatusIgnore to StatusWarning to match this semantic. SyncEngine::aboutToPropagate is used in favor of SyncEngine::syncItemDiscovered since the latter is emitted before file permission warnings are set on the SyncFileItem. SyncEngine::finished is not used since we have all the needed information in SyncEngine::itemCompleted.
2016-03-24 19:42:04 +03:00
* Copyright (C) by Jocelyn Turcotte <jturcotte@woboq.com>
Move the SocketApi business logic to a libsync SyncFileStatusTracker class This will allow testing this code and avoid going through too many layers to get notified and a file status changed.
2016-03-17 14:26:44 +03:00
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; version 2 of the License.
*
* This program is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
* or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
* for more details.
*/
#include "syncfilestatustracker.h"
#include "syncengine.h"
#include "syncjournaldb.h"
#include "syncjournalfilerecord.h"
namespace OCC {
Use a std::map for SyncFileStatusTracker problems This prevents having to define a Problem structure with dubious operator overloads to accomplish the same. Also use std::map::lower_bound to quickly iterate over the list of problems.
2016-03-29 18:29:36 +03:00
static SyncFileStatus::SyncFileStatusTag lookupProblem(const QString &pathToMatch, const std::map<QString, SyncFileStatus::SyncFileStatusTag> &problemMap)
Refactor the overlay icon logic to show errors as a warning for parent folders #3634 This also remove all smartness from the SocketApi about the status of a file and solely use info from the current and last sync. This simplifies the logic a lot and prevents any discrepancy between the status shown in the activity log and the one displayed on the overlay icon of a file. The main benefit of the additional simplicity is that we are able to push all new status of a file reliably (including warnings for parent folders) to properly update the icon on overlay implementations that don't allow us invalidating the status cache, like on OS X. Both errors and warning from the last sync are now kept in a set, which is used to also affect parent folders of an error. To make sure that errors don't become warning icons on a second sync, SyncFileItem::_hasBlacklistEntry is also interpreted as an error. This also renames StatusIgnore to StatusWarning to match this semantic. SyncEngine::aboutToPropagate is used in favor of SyncEngine::syncItemDiscovered since the latter is emitted before file permission warnings are set on the SyncFileItem. SyncEngine::finished is not used since we have all the needed information in SyncEngine::itemCompleted.
2016-03-24 19:42:04 +03:00
{
Use a std::map for SyncFileStatusTracker problems This prevents having to define a Problem structure with dubious operator overloads to accomplish the same. Also use std::map::lower_bound to quickly iterate over the list of problems.
2016-03-29 18:29:36 +03:00
auto lower = problemMap.lower_bound(pathToMatch);
for (auto it = lower; it != problemMap.cend(); ++it) {
const QString &problemPath = it->first;
SyncFileStatus::SyncFileStatusTag severity = it->second;
Cleanup after the SyncFileStatusTracker change - Add missing explicit keywords - Add doc - Comment out verbose and partly redundant qDebug statements
2016-03-29 18:39:30 +03:00
// qDebug() << Q_FUNC_INFO << pathToMatch << severity << problemPath;
Fix sibbling directories showing up as warning Looking up a/aa while an error is present in a/aab/aaba would return a warning status since a/aa is a substring of a/aab. Fix the issue by checking if the following character is a slash.
2016-03-30 12:22:01 +03:00
if (problemPath == pathToMatch) {
Use a std::map for SyncFileStatusTracker problems This prevents having to define a Problem structure with dubious operator overloads to accomplish the same. Also use std::map::lower_bound to quickly iterate over the list of problems.
2016-03-29 18:29:36 +03:00
return severity;
Simplify the root status logic Go through fileStatus like other cases to make sure that all use cases go through the same code path. This also makes sure to use lookupProblem which will use lower_bound which is more efficient for larger sets of sync problems. This also fixes the issue with lookupProblem that prevented it to properly match an empty pathToMatch, caused by the fact that the problem map contains relative paths not starting with a slash.
2016-04-28 20:33:55 +03:00
} else if (severity == SyncFileStatus::StatusError
&& problemPath.startsWith(pathToMatch)
&& (pathToMatch.isEmpty() || problemPath.at(pathToMatch.size()) == '/')) {
Refactor the overlay icon logic to show errors as a warning for parent folders #3634 This also remove all smartness from the SocketApi about the status of a file and solely use info from the current and last sync. This simplifies the logic a lot and prevents any discrepancy between the status shown in the activity log and the one displayed on the overlay icon of a file. The main benefit of the additional simplicity is that we are able to push all new status of a file reliably (including warnings for parent folders) to properly update the icon on overlay implementations that don't allow us invalidating the status cache, like on OS X. Both errors and warning from the last sync are now kept in a set, which is used to also affect parent folders of an error. To make sure that errors don't become warning icons on a second sync, SyncFileItem::_hasBlacklistEntry is also interpreted as an error. This also renames StatusIgnore to StatusWarning to match this semantic. SyncEngine::aboutToPropagate is used in favor of SyncEngine::syncItemDiscovered since the latter is emitted before file permission warnings are set on the SyncFileItem. SyncEngine::finished is not used since we have all the needed information in SyncEngine::itemCompleted.
2016-03-24 19:42:04 +03:00
return SyncFileStatus::StatusWarning;
Fix sibbling directories showing up as warning Looking up a/aa while an error is present in a/aab/aaba would return a warning status since a/aa is a substring of a/aab. Fix the issue by checking if the following character is a slash.
2016-03-30 12:22:01 +03:00
} else if (!problemPath.startsWith(pathToMatch)) {
Use a std::map for SyncFileStatusTracker problems This prevents having to define a Problem structure with dubious operator overloads to accomplish the same. Also use std::map::lower_bound to quickly iterate over the list of problems.
2016-03-29 18:29:36 +03:00
// Starting at lower_bound we get the first path that is not smaller,
Simplify the root status logic Go through fileStatus like other cases to make sure that all use cases go through the same code path. This also makes sure to use lookupProblem which will use lower_bound which is more efficient for larger sets of sync problems. This also fixes the issue with lookupProblem that prevented it to properly match an empty pathToMatch, caused by the fact that the problem map contains relative paths not starting with a slash.
2016-04-28 20:33:55 +03:00
// since: "a/" < "a/aa" < "a/aa/aaa" < "a/ab/aba"
// If problemMap keys are ["a/aa/aaa", "a/ab/aba"] and pathToMatch == "a/aa",
// lower_bound(pathToMatch) will point to "a/aa/aaa", and the moment that
Use a std::map for SyncFileStatusTracker problems This prevents having to define a Problem structure with dubious operator overloads to accomplish the same. Also use std::map::lower_bound to quickly iterate over the list of problems.
2016-03-29 18:29:36 +03:00
// problemPath.startsWith(pathToMatch) == false, we know that we've looked
// at everything that interest us.
break;
Fix sibbling directories showing up as warning Looking up a/aa while an error is present in a/aab/aaba would return a warning status since a/aa is a substring of a/aab. Fix the issue by checking if the following character is a slash.
2016-03-30 12:22:01 +03:00
}
Refactor the overlay icon logic to show errors as a warning for parent folders #3634 This also remove all smartness from the SocketApi about the status of a file and solely use info from the current and last sync. This simplifies the logic a lot and prevents any discrepancy between the status shown in the activity log and the one displayed on the overlay icon of a file. The main benefit of the additional simplicity is that we are able to push all new status of a file reliably (including warnings for parent folders) to properly update the icon on overlay implementations that don't allow us invalidating the status cache, like on OS X. Both errors and warning from the last sync are now kept in a set, which is used to also affect parent folders of an error. To make sure that errors don't become warning icons on a second sync, SyncFileItem::_hasBlacklistEntry is also interpreted as an error. This also renames StatusIgnore to StatusWarning to match this semantic. SyncEngine::aboutToPropagate is used in favor of SyncEngine::syncItemDiscovered since the latter is emitted before file permission warnings are set on the SyncFileItem. SyncEngine::finished is not used since we have all the needed information in SyncEngine::itemCompleted.
2016-03-24 19:42:04 +03:00
}
return SyncFileStatus::StatusNone;
}
Move the SocketApi business logic to a libsync SyncFileStatusTracker class This will allow testing this code and avoid going through too many layers to get notified and a file status changed.
2016-03-17 14:26:44 +03:00
/**
* Whether this item should get an ERROR icon through the Socket API.
*
* The Socket API should only present serious, permanent errors to the user.
* In particular SoftErrors should just retain their 'needs to be synced'
* icon as the problem is most likely going to resolve itself quickly and
* automatically.
*/
Refactor the overlay icon logic to show errors as a warning for parent folders #3634 This also remove all smartness from the SocketApi about the status of a file and solely use info from the current and last sync. This simplifies the logic a lot and prevents any discrepancy between the status shown in the activity log and the one displayed on the overlay icon of a file. The main benefit of the additional simplicity is that we are able to push all new status of a file reliably (including warnings for parent folders) to properly update the icon on overlay implementations that don't allow us invalidating the status cache, like on OS X. Both errors and warning from the last sync are now kept in a set, which is used to also affect parent folders of an error. To make sure that errors don't become warning icons on a second sync, SyncFileItem::_hasBlacklistEntry is also interpreted as an error. This also renames StatusIgnore to StatusWarning to match this semantic. SyncEngine::aboutToPropagate is used in favor of SyncEngine::syncItemDiscovered since the latter is emitted before file permission warnings are set on the SyncFileItem. SyncEngine::finished is not used since we have all the needed information in SyncEngine::itemCompleted.
2016-03-24 19:42:04 +03:00
static inline bool showErrorInSocketApi(const SyncFileItem& item)
Move the SocketApi business logic to a libsync SyncFileStatusTracker class This will allow testing this code and avoid going through too many layers to get notified and a file status changed.
2016-03-17 14:26:44 +03:00
{
const auto status = item._status;
[overlays] Fix folders appearing as OK even though children are still syncing #4797 This would happen if the directory would first need to be created through an mkdir propagation job. This job's itemCompleted signal would trigger the directory to show as SYNC even though its children are still propagating. Fix the issue by tracking the sync count for each file, affecting its parents. This allows us to get rid of the O(n) vector lookup for each status query, and properly track the hierachical sync status of a directory. This also removes the itemCompleted signal emission from the PropagateDirectory job. Since we only needed for overlay icons, and since this job doesn't do any direct propagation, we can remove it to ensure that we won't call itemCompleted twice for the item attached to Propagate*Mkdir jobs (since the PropagateDirectory is backed by the same SyncFileItem, instruction and status).
2016-08-05 13:12:01 +03:00
return item._instruction == CSYNC_INSTRUCTION_ERROR
|| status == SyncFileItem::NormalError
Refactor the overlay icon logic to show errors as a warning for parent folders #3634 This also remove all smartness from the SocketApi about the status of a file and solely use info from the current and last sync. This simplifies the logic a lot and prevents any discrepancy between the status shown in the activity log and the one displayed on the overlay icon of a file. The main benefit of the additional simplicity is that we are able to push all new status of a file reliably (including warnings for parent folders) to properly update the icon on overlay implementations that don't allow us invalidating the status cache, like on OS X. Both errors and warning from the last sync are now kept in a set, which is used to also affect parent folders of an error. To make sure that errors don't become warning icons on a second sync, SyncFileItem::_hasBlacklistEntry is also interpreted as an error. This also renames StatusIgnore to StatusWarning to match this semantic. SyncEngine::aboutToPropagate is used in favor of SyncEngine::syncItemDiscovered since the latter is emitted before file permission warnings are set on the SyncFileItem. SyncEngine::finished is not used since we have all the needed information in SyncEngine::itemCompleted.
2016-03-24 19:42:04 +03:00
|| status == SyncFileItem::FatalError
|| item._hasBlacklistEntry;
Move the SocketApi business logic to a libsync SyncFileStatusTracker class This will allow testing this code and avoid going through too many layers to get notified and a file status changed.
2016-03-17 14:26:44 +03:00
}
Refactor the overlay icon logic to show errors as a warning for parent folders #3634 This also remove all smartness from the SocketApi about the status of a file and solely use info from the current and last sync. This simplifies the logic a lot and prevents any discrepancy between the status shown in the activity log and the one displayed on the overlay icon of a file. The main benefit of the additional simplicity is that we are able to push all new status of a file reliably (including warnings for parent folders) to properly update the icon on overlay implementations that don't allow us invalidating the status cache, like on OS X. Both errors and warning from the last sync are now kept in a set, which is used to also affect parent folders of an error. To make sure that errors don't become warning icons on a second sync, SyncFileItem::_hasBlacklistEntry is also interpreted as an error. This also renames StatusIgnore to StatusWarning to match this semantic. SyncEngine::aboutToPropagate is used in favor of SyncEngine::syncItemDiscovered since the latter is emitted before file permission warnings are set on the SyncFileItem. SyncEngine::finished is not used since we have all the needed information in SyncEngine::itemCompleted.
2016-03-24 19:42:04 +03:00
static inline bool showWarningInSocketApi(const SyncFileItem& item)
{
const auto status = item._status;
[overlays] Fix folders appearing as OK even though children are still syncing #4797 This would happen if the directory would first need to be created through an mkdir propagation job. This job's itemCompleted signal would trigger the directory to show as SYNC even though its children are still propagating. Fix the issue by tracking the sync count for each file, affecting its parents. This allows us to get rid of the O(n) vector lookup for each status query, and properly track the hierachical sync status of a directory. This also removes the itemCompleted signal emission from the PropagateDirectory job. Since we only needed for overlay icons, and since this job doesn't do any direct propagation, we can remove it to ensure that we won't call itemCompleted twice for the item attached to Propagate*Mkdir jobs (since the PropagateDirectory is backed by the same SyncFileItem, instruction and status).
2016-08-05 13:12:01 +03:00
return item._instruction == CSYNC_INSTRUCTION_IGNORE
|| status == SyncFileItem::FileIgnored
Refactor the overlay icon logic to show errors as a warning for parent folders #3634 This also remove all smartness from the SocketApi about the status of a file and solely use info from the current and last sync. This simplifies the logic a lot and prevents any discrepancy between the status shown in the activity log and the one displayed on the overlay icon of a file. The main benefit of the additional simplicity is that we are able to push all new status of a file reliably (including warnings for parent folders) to properly update the icon on overlay implementations that don't allow us invalidating the status cache, like on OS X. Both errors and warning from the last sync are now kept in a set, which is used to also affect parent folders of an error. To make sure that errors don't become warning icons on a second sync, SyncFileItem::_hasBlacklistEntry is also interpreted as an error. This also renames StatusIgnore to StatusWarning to match this semantic. SyncEngine::aboutToPropagate is used in favor of SyncEngine::syncItemDiscovered since the latter is emitted before file permission warnings are set on the SyncFileItem. SyncEngine::finished is not used since we have all the needed information in SyncEngine::itemCompleted.
2016-03-24 19:42:04 +03:00
|| status == SyncFileItem::Conflict
|| status == SyncFileItem::Restoration;
Move the SocketApi business logic to a libsync SyncFileStatusTracker class This will allow testing this code and avoid going through too many layers to get notified and a file status changed.
2016-03-17 14:26:44 +03:00
}
SyncFileStatusTracker::SyncFileStatusTracker(SyncEngine *syncEngine)
: _syncEngine(syncEngine)
{
connect(syncEngine, SIGNAL(aboutToPropagate(SyncFileItemVector&)),
Fix the root item sync status #4682 Make sure that we push the new status when the status of the SyncEngine changed. SyncEngine::started comes a bit late, only when the propagation starts, although it's better in this case since child folders will only switch to Sync in aboutToPropagate. Also fix an issue with SyncEngine::findSyncItem when using an empty fileName; this would match and return the wrong item, even though not currently happening with the code since fileStatus won't call it with an empty fileName anymore.
2016-04-28 20:03:13 +03:00
SLOT(slotAboutToPropagate(SyncFileItemVector&)));
Connect the SocketApi directly to the SyncFileStatusTracker Don't go through the Folder->ProgressDispatcher->SocketApi route and keep the path logic in SyncFileStatusTracker.
2016-03-21 14:35:57 +03:00
connect(syncEngine, SIGNAL(itemCompleted(const SyncFileItem&, const PropagatorJob&)),
Fix the root item sync status #4682 Make sure that we push the new status when the status of the SyncEngine changed. SyncEngine::started comes a bit late, only when the propagation starts, although it's better in this case since child folders will only switch to Sync in aboutToPropagate. Also fix an issue with SyncEngine::findSyncItem when using an empty fileName; this would match and return the wrong item, even though not currently happening with the code since fileStatus won't call it with an empty fileName anymore.
2016-04-28 20:03:13 +03:00
SLOT(slotItemCompleted(const SyncFileItem&)));
[overlays] Fix folders appearing as OK even though children are still syncing #4797 This would happen if the directory would first need to be created through an mkdir propagation job. This job's itemCompleted signal would trigger the directory to show as SYNC even though its children are still propagating. Fix the issue by tracking the sync count for each file, affecting its parents. This allows us to get rid of the O(n) vector lookup for each status query, and properly track the hierachical sync status of a directory. This also removes the itemCompleted signal emission from the PropagateDirectory job. Since we only needed for overlay icons, and since this job doesn't do any direct propagation, we can remove it to ensure that we won't call itemCompleted twice for the item attached to Propagate*Mkdir jobs (since the PropagateDirectory is backed by the same SyncFileItem, instruction and status).
2016-08-05 13:12:01 +03:00
connect(syncEngine, SIGNAL(finished(bool)), SLOT(slotSyncFinished()));
Fix the root item sync status #4682 Make sure that we push the new status when the status of the SyncEngine changed. SyncEngine::started comes a bit late, only when the propagation starts, although it's better in this case since child folders will only switch to Sync in aboutToPropagate. Also fix an issue with SyncEngine::findSyncItem when using an empty fileName; this would match and return the wrong item, even though not currently happening with the code since fileStatus won't call it with an empty fileName anymore.
2016-04-28 20:03:13 +03:00
connect(syncEngine, SIGNAL(started()), SLOT(slotSyncEngineRunningChanged()));
connect(syncEngine, SIGNAL(finished(bool)), SLOT(slotSyncEngineRunningChanged()));
Move the SocketApi business logic to a libsync SyncFileStatusTracker class This will allow testing this code and avoid going through too many layers to get notified and a file status changed.
2016-03-17 14:26:44 +03:00
}
[shell/windows] Fix the windows status push not working (#4784) Since the windows implementation first does cache lookups using the path string, directories need to be passed identically as through RETRIEVE_FILE_STATUS. Change the convention to never have a trailing slash for directories in the protocol. This allows the convention to be applied without having to access the disk (since we'd need to know if the path is represented by a directory) and also matches the convention of the rest of the sync engine. Individual file manager plugins are then responsible of handling pushed paths as not ending with a trailing slash. This also: - Moves the trailing slash removal logic from the SyncFileStatusTracker to the SocketApi class - Remove the unneeded QString::normalized call in fileStatus, since this should already be done by the FolderWatcher and plugins
2016-05-06 13:32:01 +03:00
SyncFileStatus SyncFileStatusTracker::fileStatus(const QString& relativePath)
Move the SocketApi business logic to a libsync SyncFileStatusTracker class This will allow testing this code and avoid going through too many layers to get notified and a file status changed.
2016-03-17 14:26:44 +03:00
{
SocketAPI: Move the normalization closer to the data entrance (#4972) Follow-up for #4884
2016-06-15 20:37:35 +03:00
Q_ASSERT(!relativePath.endsWith(QLatin1Char('/')));
Move the SocketApi business logic to a libsync SyncFileStatusTracker class This will allow testing this code and avoid going through too many layers to get notified and a file status changed.
2016-03-17 14:26:44 +03:00
SocketAPI: Move the normalization closer to the data entrance (#4972) Follow-up for #4884
2016-06-15 20:37:35 +03:00
if (relativePath.isEmpty()) {
[overlays] Fix folders appearing as OK even though children are still syncing #4797 This would happen if the directory would first need to be created through an mkdir propagation job. This job's itemCompleted signal would trigger the directory to show as SYNC even though its children are still propagating. Fix the issue by tracking the sync count for each file, affecting its parents. This allows us to get rid of the O(n) vector lookup for each status query, and properly track the hierachical sync status of a directory. This also removes the itemCompleted signal emission from the PropagateDirectory job. Since we only needed for overlay icons, and since this job doesn't do any direct propagation, we can remove it to ensure that we won't call itemCompleted twice for the item attached to Propagate*Mkdir jobs (since the PropagateDirectory is backed by the same SyncFileItem, instruction and status).
2016-08-05 13:12:01 +03:00
// This is the root sync folder, it doesn't have an entry in the database and won't be walked by csync, so resolve manually.
return resolveSyncAndErrorStatus(QString(), NotShared);
SyncFileStatusTracker: Add a method to handle the root item.
2016-04-15 16:02:02 +03:00
}
Simplify the root status logic Go through fileStatus like other cases to make sure that all use cases go through the same code path. This also makes sure to use lookupProblem which will use lower_bound which is more efficient for larger sets of sync problems. This also fixes the issue with lookupProblem that prevented it to properly match an empty pathToMatch, caused by the fact that the problem map contains relative paths not starting with a slash.
2016-04-28 20:33:55 +03:00
Fix the SocketApi status of CSYNC_FILE_SILENTLY_EXCLUDED files Bring back the hardcoded status logic for excluded files. Since the activity log doesn't even mention those files on purpose, we can't rely on the SyncEngine to notify us about the status of those files.
2016-03-30 13:10:51 +03:00
// The SyncEngine won't notify us at all for CSYNC_FILE_SILENTLY_EXCLUDED
// and CSYNC_FILE_EXCLUDE_AND_REMOVE excludes. Even though it's possible
// that the status of CSYNC_FILE_EXCLUDE_LIST excludes will change if the user
// update the exclude list at runtime and doing it statically here removes
// our ability to notify changes through the fileStatusChanged signal,
// it's an acceptable compromize to treat all exclude types the same.
SocketAPI: Move the normalization closer to the data entrance (#4972) Follow-up for #4884
2016-06-15 20:37:35 +03:00
if( _syncEngine->excludedFiles().isExcluded(_syncEngine->localPath() + relativePath,
SyncFileStatusTracker: Remember the state of new files. In the before-propagate slot, new files that wait to be pushed to the server are remembered in the _syncProblems map. That way, the parents show a sync icon properly as asked for in #4682. After the item has been transfered properly, the item is removed from the map again because success is the default.
2016-04-21 14:56:08 +03:00
_syncEngine->localPath(),
_syncEngine->ignoreHiddenFiles()) ) {
Fix the SocketApi status of CSYNC_FILE_SILENTLY_EXCLUDED files Bring back the hardcoded status logic for excluded files. Since the activity log doesn't even mention those files on purpose, we can't rely on the SyncEngine to notify us about the status of those files.
2016-03-30 13:10:51 +03:00
return SyncFileStatus(SyncFileStatus::StatusWarning);
SyncFileStatusTracker: Remember the state of new files. In the before-propagate slot, new files that wait to be pushed to the server are remembered in the _syncProblems map. That way, the parents show a sync icon properly as asked for in #4682. After the item has been transfered properly, the item is removed from the map again because success is the default.
2016-04-21 14:56:08 +03:00
}
Fix the SocketApi status of CSYNC_FILE_SILENTLY_EXCLUDED files Bring back the hardcoded status logic for excluded files. Since the activity log doesn't even mention those files on purpose, we can't rely on the SyncEngine to notify us about the status of those files.
2016-03-30 13:10:51 +03:00
SocketAPI: Move the normalization closer to the data entrance (#4972) Follow-up for #4884
2016-06-15 20:37:35 +03:00
if ( _dirtyPaths.contains(relativePath) )
Overlay icons: Track touched files #4730 This uses the file watcher to keep track of files that were modified in order to assign them the blue icon. This is transient state that's not persisted across restarts.
2016-04-14 16:15:08 +03:00
return SyncFileStatus::StatusSync;
[overlays] Fix folders appearing as OK even though children are still syncing #4797 This would happen if the directory would first need to be created through an mkdir propagation job. This job's itemCompleted signal would trigger the directory to show as SYNC even though its children are still propagating. Fix the issue by tracking the sync count for each file, affecting its parents. This allows us to get rid of the O(n) vector lookup for each status query, and properly track the hierachical sync status of a directory. This also removes the itemCompleted signal emission from the PropagateDirectory job. Since we only needed for overlay icons, and since this job doesn't do any direct propagation, we can remove it to ensure that we won't call itemCompleted twice for the item attached to Propagate*Mkdir jobs (since the PropagateDirectory is backed by the same SyncFileItem, instruction and status).
2016-08-05 13:12:01 +03:00
// First look it up in the database to know if it's shared
SocketAPI: Move the normalization closer to the data entrance (#4972) Follow-up for #4884
2016-06-15 20:37:35 +03:00
SyncJournalFileRecord rec = _syncEngine->journal()->getFileRecord(relativePath);
SyncFileStatusTracker: Remember the state of new files. In the before-propagate slot, new files that wait to be pushed to the server are remembered in the _syncProblems map. That way, the parents show a sync icon properly as asked for in #4682. After the item has been transfered properly, the item is removed from the map again because success is the default.
2016-04-21 14:56:08 +03:00
if (rec.isValid()) {
[overlays] Fix folders appearing as OK even though children are still syncing #4797 This would happen if the directory would first need to be created through an mkdir propagation job. This job's itemCompleted signal would trigger the directory to show as SYNC even though its children are still propagating. Fix the issue by tracking the sync count for each file, affecting its parents. This allows us to get rid of the O(n) vector lookup for each status query, and properly track the hierachical sync status of a directory. This also removes the itemCompleted signal emission from the PropagateDirectory job. Since we only needed for overlay icons, and since this job doesn't do any direct propagation, we can remove it to ensure that we won't call itemCompleted twice for the item attached to Propagate*Mkdir jobs (since the PropagateDirectory is backed by the same SyncFileItem, instruction and status).
2016-08-05 13:12:01 +03:00
return resolveSyncAndErrorStatus(relativePath, rec._remotePerm.contains("S") ? Shared : NotShared);
SyncFileStatusTracker: Remember the state of new files. In the before-propagate slot, new files that wait to be pushed to the server are remembered in the _syncProblems map. That way, the parents show a sync icon properly as asked for in #4682. After the item has been transfered properly, the item is removed from the map again because success is the default.
2016-04-21 14:56:08 +03:00
}
[overlays] Fix folders appearing as OK even though children are still syncing #4797 This would happen if the directory would first need to be created through an mkdir propagation job. This job's itemCompleted signal would trigger the directory to show as SYNC even though its children are still propagating. Fix the issue by tracking the sync count for each file, affecting its parents. This allows us to get rid of the O(n) vector lookup for each status query, and properly track the hierachical sync status of a directory. This also removes the itemCompleted signal emission from the PropagateDirectory job. Since we only needed for overlay icons, and since this job doesn't do any direct propagation, we can remove it to ensure that we won't call itemCompleted twice for the item attached to Propagate*Mkdir jobs (since the PropagateDirectory is backed by the same SyncFileItem, instruction and status).
2016-08-05 13:12:01 +03:00
// Must be a new file not yet in the database, check if it's syncing or has an error.
return resolveSyncAndErrorStatus(relativePath, NotShared, PathUnknown);
Move the SocketApi business logic to a libsync SyncFileStatusTracker class This will allow testing this code and avoid going through too many layers to get notified and a file status changed.
2016-03-17 14:26:44 +03:00
}
Overlay icons: Track touched files #4730 This uses the file watcher to keep track of files that were modified in order to assign them the blue icon. This is transient state that's not persisted across restarts.
2016-04-14 16:15:08 +03:00
void SyncFileStatusTracker::slotPathTouched(const QString& fileName)
{
QString folderPath = _syncEngine->localPath();
Q_ASSERT(fileName.startsWith(folderPath));
QString localPath = fileName.mid(folderPath.size());
_dirtyPaths.insert(localPath);
emit fileStatusChanged(fileName, SyncFileStatus::StatusSync);
}
[overlays] Fix folders appearing as OK even though children are still syncing #4797 This would happen if the directory would first need to be created through an mkdir propagation job. This job's itemCompleted signal would trigger the directory to show as SYNC even though its children are still propagating. Fix the issue by tracking the sync count for each file, affecting its parents. This allows us to get rid of the O(n) vector lookup for each status query, and properly track the hierachical sync status of a directory. This also removes the itemCompleted signal emission from the PropagateDirectory job. Since we only needed for overlay icons, and since this job doesn't do any direct propagation, we can remove it to ensure that we won't call itemCompleted twice for the item attached to Propagate*Mkdir jobs (since the PropagateDirectory is backed by the same SyncFileItem, instruction and status).
2016-08-05 13:12:01 +03:00
void SyncFileStatusTracker::incSyncCount(const QString &relativePath, EmitStatusChangeFlag emitStatusChange)
{
// Will return 0 (and increase to 1) if the path wasn't in the map yet
int count = _syncCount[relativePath]++;
if (!count) {
if (emitStatusChange)
emit fileStatusChanged(getSystemDestination(relativePath), fileStatus(relativePath));
// We passed from OK to SYNC, increment the parent to keep it marked as
// SYNC while we propagate ourselves and our own children.
Q_ASSERT(!relativePath.endsWith('/'));
int lastSlashIndex = relativePath.lastIndexOf('/');
if (lastSlashIndex != -1)
incSyncCount(relativePath.left(lastSlashIndex), EmitStatusChange);
else if (!relativePath.isEmpty())
incSyncCount(QString(), EmitStatusChange);
}
}
void SyncFileStatusTracker::decSyncCount(const QString &relativePath, EmitStatusChangeFlag emitStatusChange)
{
int count = --_syncCount[relativePath];
if (!count) {
// Remove from the map, same as 0
_syncCount.remove(relativePath);
if (emitStatusChange)
emit fileStatusChanged(getSystemDestination(relativePath), fileStatus(relativePath));
// We passed from SYNC to OK, decrement our parent.
Q_ASSERT(!relativePath.endsWith('/'));
int lastSlashIndex = relativePath.lastIndexOf('/');
if (lastSlashIndex != -1)
decSyncCount(relativePath.left(lastSlashIndex), EmitStatusChange);
else if (!relativePath.isEmpty())
decSyncCount(QString(), EmitStatusChange);
}
}
Move the SocketApi business logic to a libsync SyncFileStatusTracker class This will allow testing this code and avoid going through too many layers to get notified and a file status changed.
2016-03-17 14:26:44 +03:00
void SyncFileStatusTracker::slotAboutToPropagate(SyncFileItemVector& items)
{
[overlays] Fix folders appearing as OK even though children are still syncing #4797 This would happen if the directory would first need to be created through an mkdir propagation job. This job's itemCompleted signal would trigger the directory to show as SYNC even though its children are still propagating. Fix the issue by tracking the sync count for each file, affecting its parents. This allows us to get rid of the O(n) vector lookup for each status query, and properly track the hierachical sync status of a directory. This also removes the itemCompleted signal emission from the PropagateDirectory job. Since we only needed for overlay icons, and since this job doesn't do any direct propagation, we can remove it to ensure that we won't call itemCompleted twice for the item attached to Propagate*Mkdir jobs (since the PropagateDirectory is backed by the same SyncFileItem, instruction and status).
2016-08-05 13:12:01 +03:00
Q_ASSERT(_syncCount.isEmpty());
Use a std::map for SyncFileStatusTracker problems This prevents having to define a Problem structure with dubious operator overloads to accomplish the same. Also use std::map::lower_bound to quickly iterate over the list of problems.
2016-03-29 18:29:36 +03:00
std::map<QString, SyncFileStatus::SyncFileStatusTag> oldProblems;
Refactor the overlay icon logic to show errors as a warning for parent folders #3634 This also remove all smartness from the SocketApi about the status of a file and solely use info from the current and last sync. This simplifies the logic a lot and prevents any discrepancy between the status shown in the activity log and the one displayed on the overlay icon of a file. The main benefit of the additional simplicity is that we are able to push all new status of a file reliably (including warnings for parent folders) to properly update the icon on overlay implementations that don't allow us invalidating the status cache, like on OS X. Both errors and warning from the last sync are now kept in a set, which is used to also affect parent folders of an error. To make sure that errors don't become warning icons on a second sync, SyncFileItem::_hasBlacklistEntry is also interpreted as an error. This also renames StatusIgnore to StatusWarning to match this semantic. SyncEngine::aboutToPropagate is used in favor of SyncEngine::syncItemDiscovered since the latter is emitted before file permission warnings are set on the SyncFileItem. SyncEngine::finished is not used since we have all the needed information in SyncEngine::itemCompleted.
2016-03-24 19:42:04 +03:00
std::swap(_syncProblems, oldProblems);
Move the SocketApi business logic to a libsync SyncFileStatusTracker class This will allow testing this code and avoid going through too many layers to get notified and a file status changed.
2016-03-17 14:26:44 +03:00
Refactor the overlay icon logic to show errors as a warning for parent folders #3634 This also remove all smartness from the SocketApi about the status of a file and solely use info from the current and last sync. This simplifies the logic a lot and prevents any discrepancy between the status shown in the activity log and the one displayed on the overlay icon of a file. The main benefit of the additional simplicity is that we are able to push all new status of a file reliably (including warnings for parent folders) to properly update the icon on overlay implementations that don't allow us invalidating the status cache, like on OS X. Both errors and warning from the last sync are now kept in a set, which is used to also affect parent folders of an error. To make sure that errors don't become warning icons on a second sync, SyncFileItem::_hasBlacklistEntry is also interpreted as an error. This also renames StatusIgnore to StatusWarning to match this semantic. SyncEngine::aboutToPropagate is used in favor of SyncEngine::syncItemDiscovered since the latter is emitted before file permission warnings are set on the SyncFileItem. SyncEngine::finished is not used since we have all the needed information in SyncEngine::itemCompleted.
2016-03-24 19:42:04 +03:00
foreach (const SyncFileItemPtr &item, items) {
[overlays] Fix folders appearing as OK even though children are still syncing #4797 This would happen if the directory would first need to be created through an mkdir propagation job. This job's itemCompleted signal would trigger the directory to show as SYNC even though its children are still propagating. Fix the issue by tracking the sync count for each file, affecting its parents. This allows us to get rid of the O(n) vector lookup for each status query, and properly track the hierachical sync status of a directory. This also removes the itemCompleted signal emission from the PropagateDirectory job. Since we only needed for overlay icons, and since this job doesn't do any direct propagation, we can remove it to ensure that we won't call itemCompleted twice for the item attached to Propagate*Mkdir jobs (since the PropagateDirectory is backed by the same SyncFileItem, instruction and status).
2016-08-05 13:12:01 +03:00
// qDebug() << Q_FUNC_INFO << "Investigating" << item->destination() << item->_status << item->_instruction;
Refactor the overlay icon logic to show errors as a warning for parent folders #3634 This also remove all smartness from the SocketApi about the status of a file and solely use info from the current and last sync. This simplifies the logic a lot and prevents any discrepancy between the status shown in the activity log and the one displayed on the overlay icon of a file. The main benefit of the additional simplicity is that we are able to push all new status of a file reliably (including warnings for parent folders) to properly update the icon on overlay implementations that don't allow us invalidating the status cache, like on OS X. Both errors and warning from the last sync are now kept in a set, which is used to also affect parent folders of an error. To make sure that errors don't become warning icons on a second sync, SyncFileItem::_hasBlacklistEntry is also interpreted as an error. This also renames StatusIgnore to StatusWarning to match this semantic. SyncEngine::aboutToPropagate is used in favor of SyncEngine::syncItemDiscovered since the latter is emitted before file permission warnings are set on the SyncFileItem. SyncEngine::finished is not used since we have all the needed information in SyncEngine::itemCompleted.
2016-03-24 19:42:04 +03:00
SyncFileStatusTracker: Remember the state of new files. In the before-propagate slot, new files that wait to be pushed to the server are remembered in the _syncProblems map. That way, the parents show a sync icon properly as asked for in #4682. After the item has been transfered properly, the item is removed from the map again because success is the default.
2016-04-21 14:56:08 +03:00
if (showErrorInSocketApi(*item)) {
Use a std::map for SyncFileStatusTracker problems This prevents having to define a Problem structure with dubious operator overloads to accomplish the same. Also use std::map::lower_bound to quickly iterate over the list of problems.
2016-03-29 18:29:36 +03:00
_syncProblems[item->_file] = SyncFileStatus::StatusError;
Make sure that we invalidate parents on blacklisted items Add a missing call that we currently only do in slotItemCompleted. This would normally only affect the first sync and would have gotten properly update at the end of the sync anyway.
2016-08-05 18:18:16 +03:00
invalidateParentPaths(item->destination());
SyncFileStatusTracker: Remember the state of new files. In the before-propagate slot, new files that wait to be pushed to the server are remembered in the _syncProblems map. That way, the parents show a sync icon properly as asked for in #4682. After the item has been transfered properly, the item is removed from the map again because success is the default.
2016-04-21 14:56:08 +03:00
} else if (showWarningInSocketApi(*item)) {
Use a std::map for SyncFileStatusTracker problems This prevents having to define a Problem structure with dubious operator overloads to accomplish the same. Also use std::map::lower_bound to quickly iterate over the list of problems.
2016-03-29 18:29:36 +03:00
_syncProblems[item->_file] = SyncFileStatus::StatusWarning;
SyncFileStatusTracker: Remember the state of new files. In the before-propagate slot, new files that wait to be pushed to the server are remembered in the _syncProblems map. That way, the parents show a sync icon properly as asked for in #4682. After the item has been transfered properly, the item is removed from the map again because success is the default.
2016-04-21 14:56:08 +03:00
}
[overlays] Fix folders appearing as OK even though children are still syncing #4797 This would happen if the directory would first need to be created through an mkdir propagation job. This job's itemCompleted signal would trigger the directory to show as SYNC even though its children are still propagating. Fix the issue by tracking the sync count for each file, affecting its parents. This allows us to get rid of the O(n) vector lookup for each status query, and properly track the hierachical sync status of a directory. This also removes the itemCompleted signal emission from the PropagateDirectory job. Since we only needed for overlay icons, and since this job doesn't do any direct propagation, we can remove it to ensure that we won't call itemCompleted twice for the item attached to Propagate*Mkdir jobs (since the PropagateDirectory is backed by the same SyncFileItem, instruction and status).
2016-08-05 13:12:01 +03:00
// Mark this path as syncing for instructions that will result in propagation,
// but DontEmitStatusChange since we're going to emit for ourselves using the
// info in the SyncFileItem we received, parents will still be emit if needed.
if (item->_instruction != CSYNC_INSTRUCTION_NONE
&& item->_instruction != CSYNC_INSTRUCTION_UPDATE_METADATA
&& item->_instruction != CSYNC_INSTRUCTION_IGNORE
&& item->_instruction != CSYNC_INSTRUCTION_ERROR) {
incSyncCount(item->destination(), DontEmitStatusChange);
}
SocketAPI: Push new status of dirty files regardless when not synced (#4970) The FolderWatcher inserts files to be marked as SYNC and we currently assume that all file statuses will be updated by the following sync. It's however possible that the FolderWatcher notify us of a change that csync won't consider necessary to propagate, in which case a new status wouldn't be pushed and the file manager would continue showing this file as syncing. Re-push the file status when emptying the dirty files list before propagating to avoid this issue, most likely the OK status.
2016-06-16 16:27:10 +03:00
_dirtyPaths.remove(item->destination());
[overlays] Fix folders appearing as OK even though children are still syncing #4797 This would happen if the directory would first need to be created through an mkdir propagation job. This job's itemCompleted signal would trigger the directory to show as SYNC even though its children are still propagating. Fix the issue by tracking the sync count for each file, affecting its parents. This allows us to get rid of the O(n) vector lookup for each status query, and properly track the hierachical sync status of a directory. This also removes the itemCompleted signal emission from the PropagateDirectory job. Since we only needed for overlay icons, and since this job doesn't do any direct propagation, we can remove it to ensure that we won't call itemCompleted twice for the item attached to Propagate*Mkdir jobs (since the PropagateDirectory is backed by the same SyncFileItem, instruction and status).
2016-08-05 13:12:01 +03:00
emit fileStatusChanged(getSystemDestination(item->destination()), resolveSyncAndErrorStatus(item->destination(), item->_remotePerm.contains("S") ? Shared : NotShared));
Refactor the overlay icon logic to show errors as a warning for parent folders #3634 This also remove all smartness from the SocketApi about the status of a file and solely use info from the current and last sync. This simplifies the logic a lot and prevents any discrepancy between the status shown in the activity log and the one displayed on the overlay icon of a file. The main benefit of the additional simplicity is that we are able to push all new status of a file reliably (including warnings for parent folders) to properly update the icon on overlay implementations that don't allow us invalidating the status cache, like on OS X. Both errors and warning from the last sync are now kept in a set, which is used to also affect parent folders of an error. To make sure that errors don't become warning icons on a second sync, SyncFileItem::_hasBlacklistEntry is also interpreted as an error. This also renames StatusIgnore to StatusWarning to match this semantic. SyncEngine::aboutToPropagate is used in favor of SyncEngine::syncItemDiscovered since the latter is emitted before file permission warnings are set on the SyncFileItem. SyncEngine::finished is not used since we have all the needed information in SyncEngine::itemCompleted.
2016-03-24 19:42:04 +03:00
}
SocketAPI: Push new status of dirty files regardless when not synced (#4970) The FolderWatcher inserts files to be marked as SYNC and we currently assume that all file statuses will be updated by the following sync. It's however possible that the FolderWatcher notify us of a change that csync won't consider necessary to propagate, in which case a new status wouldn't be pushed and the file manager would continue showing this file as syncing. Re-push the file status when emptying the dirty files list before propagating to avoid this issue, most likely the OK status.
2016-06-16 16:27:10 +03:00
// Some metadata status won't trigger files to be synced, make sure that we
// push the OK status for dirty files that don't need to be propagated.
// Swap into a copy since fileStatus() reads _dirtyPaths to determine the status
QSet<QString> oldDirtyPaths;
std::swap(_dirtyPaths, oldDirtyPaths);
Fix Qt4 build
2016-07-11 13:27:59 +03:00
for (auto it = oldDirtyPaths.constBegin(); it != oldDirtyPaths.constEnd(); ++it)
SocketAPI: Push new status of dirty files regardless when not synced (#4970) The FolderWatcher inserts files to be marked as SYNC and we currently assume that all file statuses will be updated by the following sync. It's however possible that the FolderWatcher notify us of a change that csync won't consider necessary to propagate, in which case a new status wouldn't be pushed and the file manager would continue showing this file as syncing. Re-push the file status when emptying the dirty files list before propagating to avoid this issue, most likely the OK status.
2016-06-16 16:27:10 +03:00
emit fileStatusChanged(getSystemDestination(*it), fileStatus(*it));
Refactor the overlay icon logic to show errors as a warning for parent folders #3634 This also remove all smartness from the SocketApi about the status of a file and solely use info from the current and last sync. This simplifies the logic a lot and prevents any discrepancy between the status shown in the activity log and the one displayed on the overlay icon of a file. The main benefit of the additional simplicity is that we are able to push all new status of a file reliably (including warnings for parent folders) to properly update the icon on overlay implementations that don't allow us invalidating the status cache, like on OS X. Both errors and warning from the last sync are now kept in a set, which is used to also affect parent folders of an error. To make sure that errors don't become warning icons on a second sync, SyncFileItem::_hasBlacklistEntry is also interpreted as an error. This also renames StatusIgnore to StatusWarning to match this semantic. SyncEngine::aboutToPropagate is used in favor of SyncEngine::syncItemDiscovered since the latter is emitted before file permission warnings are set on the SyncFileItem. SyncEngine::finished is not used since we have all the needed information in SyncEngine::itemCompleted.
2016-03-24 19:42:04 +03:00
// Make sure to push any status that might have been resolved indirectly since the last sync
// (like an error file being deleted from disk)
for (auto it = _syncProblems.begin(); it != _syncProblems.end(); ++it)
Use a std::map for SyncFileStatusTracker problems This prevents having to define a Problem structure with dubious operator overloads to accomplish the same. Also use std::map::lower_bound to quickly iterate over the list of problems.
2016-03-29 18:29:36 +03:00
oldProblems.erase(it->first);
Refactor the overlay icon logic to show errors as a warning for parent folders #3634 This also remove all smartness from the SocketApi about the status of a file and solely use info from the current and last sync. This simplifies the logic a lot and prevents any discrepancy between the status shown in the activity log and the one displayed on the overlay icon of a file. The main benefit of the additional simplicity is that we are able to push all new status of a file reliably (including warnings for parent folders) to properly update the icon on overlay implementations that don't allow us invalidating the status cache, like on OS X. Both errors and warning from the last sync are now kept in a set, which is used to also affect parent folders of an error. To make sure that errors don't become warning icons on a second sync, SyncFileItem::_hasBlacklistEntry is also interpreted as an error. This also renames StatusIgnore to StatusWarning to match this semantic. SyncEngine::aboutToPropagate is used in favor of SyncEngine::syncItemDiscovered since the latter is emitted before file permission warnings are set on the SyncFileItem. SyncEngine::finished is not used since we have all the needed information in SyncEngine::itemCompleted.
2016-03-24 19:42:04 +03:00
for (auto it = oldProblems.begin(); it != oldProblems.end(); ++it) {
Use a std::map for SyncFileStatusTracker problems This prevents having to define a Problem structure with dubious operator overloads to accomplish the same. Also use std::map::lower_bound to quickly iterate over the list of problems.
2016-03-29 18:29:36 +03:00
const QString &path = it->first;
SyncFileStatus::SyncFileStatusTag severity = it->second;
if (severity == SyncFileStatus::StatusError)
invalidateParentPaths(path);
[shell/windows] Fix the windows status push not working (#4784) Since the windows implementation first does cache lookups using the path string, directories need to be passed identically as through RETRIEVE_FILE_STATUS. Change the convention to never have a trailing slash for directories in the protocol. This allows the convention to be applied without having to access the disk (since we'd need to know if the path is represented by a directory) and also matches the convention of the rest of the sync engine. Individual file manager plugins are then responsible of handling pushed paths as not ending with a trailing slash. This also: - Moves the trailing slash removal logic from the SyncFileStatusTracker to the SocketApi class - Remove the unneeded QString::normalized call in fileStatus, since this should already be done by the FolderWatcher and plugins
2016-05-06 13:32:01 +03:00
emit fileStatusChanged(getSystemDestination(path), fileStatus(path));
Refactor the overlay icon logic to show errors as a warning for parent folders #3634 This also remove all smartness from the SocketApi about the status of a file and solely use info from the current and last sync. This simplifies the logic a lot and prevents any discrepancy between the status shown in the activity log and the one displayed on the overlay icon of a file. The main benefit of the additional simplicity is that we are able to push all new status of a file reliably (including warnings for parent folders) to properly update the icon on overlay implementations that don't allow us invalidating the status cache, like on OS X. Both errors and warning from the last sync are now kept in a set, which is used to also affect parent folders of an error. To make sure that errors don't become warning icons on a second sync, SyncFileItem::_hasBlacklistEntry is also interpreted as an error. This also renames StatusIgnore to StatusWarning to match this semantic. SyncEngine::aboutToPropagate is used in favor of SyncEngine::syncItemDiscovered since the latter is emitted before file permission warnings are set on the SyncFileItem. SyncEngine::finished is not used since we have all the needed information in SyncEngine::itemCompleted.
2016-03-24 19:42:04 +03:00
}
Move the SocketApi business logic to a libsync SyncFileStatusTracker class This will allow testing this code and avoid going through too many layers to get notified and a file status changed.
2016-03-17 14:26:44 +03:00
}
void SyncFileStatusTracker::slotItemCompleted(const SyncFileItem &item)
{
[overlays] Fix folders appearing as OK even though children are still syncing #4797 This would happen if the directory would first need to be created through an mkdir propagation job. This job's itemCompleted signal would trigger the directory to show as SYNC even though its children are still propagating. Fix the issue by tracking the sync count for each file, affecting its parents. This allows us to get rid of the O(n) vector lookup for each status query, and properly track the hierachical sync status of a directory. This also removes the itemCompleted signal emission from the PropagateDirectory job. Since we only needed for overlay icons, and since this job doesn't do any direct propagation, we can remove it to ensure that we won't call itemCompleted twice for the item attached to Propagate*Mkdir jobs (since the PropagateDirectory is backed by the same SyncFileItem, instruction and status).
2016-08-05 13:12:01 +03:00
// qDebug() << Q_FUNC_INFO << item.destination() << item._status << item._instruction;
Refactor the overlay icon logic to show errors as a warning for parent folders #3634 This also remove all smartness from the SocketApi about the status of a file and solely use info from the current and last sync. This simplifies the logic a lot and prevents any discrepancy between the status shown in the activity log and the one displayed on the overlay icon of a file. The main benefit of the additional simplicity is that we are able to push all new status of a file reliably (including warnings for parent folders) to properly update the icon on overlay implementations that don't allow us invalidating the status cache, like on OS X. Both errors and warning from the last sync are now kept in a set, which is used to also affect parent folders of an error. To make sure that errors don't become warning icons on a second sync, SyncFileItem::_hasBlacklistEntry is also interpreted as an error. This also renames StatusIgnore to StatusWarning to match this semantic. SyncEngine::aboutToPropagate is used in favor of SyncEngine::syncItemDiscovered since the latter is emitted before file permission warnings are set on the SyncFileItem. SyncEngine::finished is not used since we have all the needed information in SyncEngine::itemCompleted.
2016-03-24 19:42:04 +03:00
Move the SocketApi business logic to a libsync SyncFileStatusTracker class This will allow testing this code and avoid going through too many layers to get notified and a file status changed.
2016-03-17 14:26:44 +03:00
if (showErrorInSocketApi(item)) {
Use a std::map for SyncFileStatusTracker problems This prevents having to define a Problem structure with dubious operator overloads to accomplish the same. Also use std::map::lower_bound to quickly iterate over the list of problems.
2016-03-29 18:29:36 +03:00
_syncProblems[item._file] = SyncFileStatus::StatusError;
Refactor the overlay icon logic to show errors as a warning for parent folders #3634 This also remove all smartness from the SocketApi about the status of a file and solely use info from the current and last sync. This simplifies the logic a lot and prevents any discrepancy between the status shown in the activity log and the one displayed on the overlay icon of a file. The main benefit of the additional simplicity is that we are able to push all new status of a file reliably (including warnings for parent folders) to properly update the icon on overlay implementations that don't allow us invalidating the status cache, like on OS X. Both errors and warning from the last sync are now kept in a set, which is used to also affect parent folders of an error. To make sure that errors don't become warning icons on a second sync, SyncFileItem::_hasBlacklistEntry is also interpreted as an error. This also renames StatusIgnore to StatusWarning to match this semantic. SyncEngine::aboutToPropagate is used in favor of SyncEngine::syncItemDiscovered since the latter is emitted before file permission warnings are set on the SyncFileItem. SyncEngine::finished is not used since we have all the needed information in SyncEngine::itemCompleted.
2016-03-24 19:42:04 +03:00
invalidateParentPaths(item.destination());
} else if (showWarningInSocketApi(item)) {
Use a std::map for SyncFileStatusTracker problems This prevents having to define a Problem structure with dubious operator overloads to accomplish the same. Also use std::map::lower_bound to quickly iterate over the list of problems.
2016-03-29 18:29:36 +03:00
_syncProblems[item._file] = SyncFileStatus::StatusWarning;
Refactor the overlay icon logic to show errors as a warning for parent folders #3634 This also remove all smartness from the SocketApi about the status of a file and solely use info from the current and last sync. This simplifies the logic a lot and prevents any discrepancy between the status shown in the activity log and the one displayed on the overlay icon of a file. The main benefit of the additional simplicity is that we are able to push all new status of a file reliably (including warnings for parent folders) to properly update the icon on overlay implementations that don't allow us invalidating the status cache, like on OS X. Both errors and warning from the last sync are now kept in a set, which is used to also affect parent folders of an error. To make sure that errors don't become warning icons on a second sync, SyncFileItem::_hasBlacklistEntry is also interpreted as an error. This also renames StatusIgnore to StatusWarning to match this semantic. SyncEngine::aboutToPropagate is used in favor of SyncEngine::syncItemDiscovered since the latter is emitted before file permission warnings are set on the SyncFileItem. SyncEngine::finished is not used since we have all the needed information in SyncEngine::itemCompleted.
2016-03-24 19:42:04 +03:00
} else {
Fix assert on restore after propagation (#4823) The assert was there to make sure that this case wasn't happening to eventually be properly tested. Remove the assert for now but this codepath should eventually be unit tested using this specific situation.
2016-05-11 19:16:46 +03:00
_syncProblems.erase(item._file);
Move the SocketApi business logic to a libsync SyncFileStatusTracker class This will allow testing this code and avoid going through too many layers to get notified and a file status changed.
2016-03-17 14:26:44 +03:00
}
Connect the SocketApi directly to the SyncFileStatusTracker Don't go through the Folder->ProgressDispatcher->SocketApi route and keep the path logic in SyncFileStatusTracker.
2016-03-21 14:35:57 +03:00
[overlays] Fix folders appearing as OK even though children are still syncing #4797 This would happen if the directory would first need to be created through an mkdir propagation job. This job's itemCompleted signal would trigger the directory to show as SYNC even though its children are still propagating. Fix the issue by tracking the sync count for each file, affecting its parents. This allows us to get rid of the O(n) vector lookup for each status query, and properly track the hierachical sync status of a directory. This also removes the itemCompleted signal emission from the PropagateDirectory job. Since we only needed for overlay icons, and since this job doesn't do any direct propagation, we can remove it to ensure that we won't call itemCompleted twice for the item attached to Propagate*Mkdir jobs (since the PropagateDirectory is backed by the same SyncFileItem, instruction and status).
2016-08-05 13:12:01 +03:00
// decSyncCount calls *must* be symetric with incSyncCount calls in slotAboutToPropagate
if (item._instruction != CSYNC_INSTRUCTION_NONE
&& item._instruction != CSYNC_INSTRUCTION_UPDATE_METADATA
&& item._instruction != CSYNC_INSTRUCTION_IGNORE
&& item._instruction != CSYNC_INSTRUCTION_ERROR) {
decSyncCount(item.destination(), DontEmitStatusChange);
}
emit fileStatusChanged(getSystemDestination(item.destination()), resolveSyncAndErrorStatus(item.destination(), item._remotePerm.contains("S") ? Shared : NotShared));
}
void SyncFileStatusTracker::slotSyncFinished()
{
// Clear the sync counts to reduce the impact of unsymetrical inc/dec calls (e.g. when directory job abort)
QHash<QString, int> oldSyncCount;
std::swap(_syncCount, oldSyncCount);
for (auto it = oldSyncCount.begin(); it != oldSyncCount.end(); ++it)
emit fileStatusChanged(getSystemDestination(it.key()), fileStatus(it.key()));
Connect the SocketApi directly to the SyncFileStatusTracker Don't go through the Folder->ProgressDispatcher->SocketApi route and keep the path logic in SyncFileStatusTracker.
2016-03-21 14:35:57 +03:00
}
Fix the root item sync status #4682 Make sure that we push the new status when the status of the SyncEngine changed. SyncEngine::started comes a bit late, only when the propagation starts, although it's better in this case since child folders will only switch to Sync in aboutToPropagate. Also fix an issue with SyncEngine::findSyncItem when using an empty fileName; this would match and return the wrong item, even though not currently happening with the code since fileStatus won't call it with an empty fileName anymore.
2016-04-28 20:03:13 +03:00
void SyncFileStatusTracker::slotSyncEngineRunningChanged()
{
[overlays] Fix folders appearing as OK even though children are still syncing #4797 This would happen if the directory would first need to be created through an mkdir propagation job. This job's itemCompleted signal would trigger the directory to show as SYNC even though its children are still propagating. Fix the issue by tracking the sync count for each file, affecting its parents. This allows us to get rid of the O(n) vector lookup for each status query, and properly track the hierachical sync status of a directory. This also removes the itemCompleted signal emission from the PropagateDirectory job. Since we only needed for overlay icons, and since this job doesn't do any direct propagation, we can remove it to ensure that we won't call itemCompleted twice for the item attached to Propagate*Mkdir jobs (since the PropagateDirectory is backed by the same SyncFileItem, instruction and status).
2016-08-05 13:12:01 +03:00
emit fileStatusChanged(_syncEngine->localPath(), resolveSyncAndErrorStatus(QString(), NotShared));
Fix the root item sync status #4682 Make sure that we push the new status when the status of the SyncEngine changed. SyncEngine::started comes a bit late, only when the propagation starts, although it's better in this case since child folders will only switch to Sync in aboutToPropagate. Also fix an issue with SyncEngine::findSyncItem when using an empty fileName; this would match and return the wrong item, even though not currently happening with the code since fileStatus won't call it with an empty fileName anymore.
2016-04-28 20:03:13 +03:00
}
[overlays] Fix folders appearing as OK even though children are still syncing #4797 This would happen if the directory would first need to be created through an mkdir propagation job. This job's itemCompleted signal would trigger the directory to show as SYNC even though its children are still propagating. Fix the issue by tracking the sync count for each file, affecting its parents. This allows us to get rid of the O(n) vector lookup for each status query, and properly track the hierachical sync status of a directory. This also removes the itemCompleted signal emission from the PropagateDirectory job. Since we only needed for overlay icons, and since this job doesn't do any direct propagation, we can remove it to ensure that we won't call itemCompleted twice for the item attached to Propagate*Mkdir jobs (since the PropagateDirectory is backed by the same SyncFileItem, instruction and status).
2016-08-05 13:12:01 +03:00
SyncFileStatus SyncFileStatusTracker::resolveSyncAndErrorStatus(const QString &relativePath, SharedFlag isShared, PathKnownFlag isPathKnown)
Connect the SocketApi directly to the SyncFileStatusTracker Don't go through the Folder->ProgressDispatcher->SocketApi route and keep the path logic in SyncFileStatusTracker.
2016-03-21 14:35:57 +03:00
{
[overlays] Fix folders appearing as OK even though children are still syncing #4797 This would happen if the directory would first need to be created through an mkdir propagation job. This job's itemCompleted signal would trigger the directory to show as SYNC even though its children are still propagating. Fix the issue by tracking the sync count for each file, affecting its parents. This allows us to get rid of the O(n) vector lookup for each status query, and properly track the hierachical sync status of a directory. This also removes the itemCompleted signal emission from the PropagateDirectory job. Since we only needed for overlay icons, and since this job doesn't do any direct propagation, we can remove it to ensure that we won't call itemCompleted twice for the item attached to Propagate*Mkdir jobs (since the PropagateDirectory is backed by the same SyncFileItem, instruction and status).
2016-08-05 13:12:01 +03:00
// If it's a new file and that we're not syncing it yet,
// don't show any icon and wait for the filesystem watcher to trigger a sync.
SyncFileStatus status(isPathKnown ? SyncFileStatus::StatusUpToDate : SyncFileStatus::StatusNone);
if (_syncCount.value(relativePath)) {
Refactor the overlay icon logic to show errors as a warning for parent folders #3634 This also remove all smartness from the SocketApi about the status of a file and solely use info from the current and last sync. This simplifies the logic a lot and prevents any discrepancy between the status shown in the activity log and the one displayed on the overlay icon of a file. The main benefit of the additional simplicity is that we are able to push all new status of a file reliably (including warnings for parent folders) to properly update the icon on overlay implementations that don't allow us invalidating the status cache, like on OS X. Both errors and warning from the last sync are now kept in a set, which is used to also affect parent folders of an error. To make sure that errors don't become warning icons on a second sync, SyncFileItem::_hasBlacklistEntry is also interpreted as an error. This also renames StatusIgnore to StatusWarning to match this semantic. SyncEngine::aboutToPropagate is used in favor of SyncEngine::syncItemDiscovered since the latter is emitted before file permission warnings are set on the SyncFileItem. SyncEngine::finished is not used since we have all the needed information in SyncEngine::itemCompleted.
2016-03-24 19:42:04 +03:00
status.set(SyncFileStatus::StatusSync);
} else {
// After a sync finished, we need to show the users issues from that last sync like the activity list does.
// Also used for parent directories showing a warning for an error child.
[overlays] Fix folders appearing as OK even though children are still syncing #4797 This would happen if the directory would first need to be created through an mkdir propagation job. This job's itemCompleted signal would trigger the directory to show as SYNC even though its children are still propagating. Fix the issue by tracking the sync count for each file, affecting its parents. This allows us to get rid of the O(n) vector lookup for each status query, and properly track the hierachical sync status of a directory. This also removes the itemCompleted signal emission from the PropagateDirectory job. Since we only needed for overlay icons, and since this job doesn't do any direct propagation, we can remove it to ensure that we won't call itemCompleted twice for the item attached to Propagate*Mkdir jobs (since the PropagateDirectory is backed by the same SyncFileItem, instruction and status).
2016-08-05 13:12:01 +03:00
SyncFileStatus::SyncFileStatusTag problemStatus = lookupProblem(relativePath, _syncProblems);
Refactor the overlay icon logic to show errors as a warning for parent folders #3634 This also remove all smartness from the SocketApi about the status of a file and solely use info from the current and last sync. This simplifies the logic a lot and prevents any discrepancy between the status shown in the activity log and the one displayed on the overlay icon of a file. The main benefit of the additional simplicity is that we are able to push all new status of a file reliably (including warnings for parent folders) to properly update the icon on overlay implementations that don't allow us invalidating the status cache, like on OS X. Both errors and warning from the last sync are now kept in a set, which is used to also affect parent folders of an error. To make sure that errors don't become warning icons on a second sync, SyncFileItem::_hasBlacklistEntry is also interpreted as an error. This also renames StatusIgnore to StatusWarning to match this semantic. SyncEngine::aboutToPropagate is used in favor of SyncEngine::syncItemDiscovered since the latter is emitted before file permission warnings are set on the SyncFileItem. SyncEngine::finished is not used since we have all the needed information in SyncEngine::itemCompleted.
2016-03-24 19:42:04 +03:00
if (problemStatus != SyncFileStatus::StatusNone)
status.set(problemStatus);
Connect the SocketApi directly to the SyncFileStatusTracker Don't go through the Folder->ProgressDispatcher->SocketApi route and keep the path logic in SyncFileStatusTracker.
2016-03-21 14:35:57 +03:00
}
[overlays] Fix folders appearing as OK even though children are still syncing #4797 This would happen if the directory would first need to be created through an mkdir propagation job. This job's itemCompleted signal would trigger the directory to show as SYNC even though its children are still propagating. Fix the issue by tracking the sync count for each file, affecting its parents. This allows us to get rid of the O(n) vector lookup for each status query, and properly track the hierachical sync status of a directory. This also removes the itemCompleted signal emission from the PropagateDirectory job. Since we only needed for overlay icons, and since this job doesn't do any direct propagation, we can remove it to ensure that we won't call itemCompleted twice for the item attached to Propagate*Mkdir jobs (since the PropagateDirectory is backed by the same SyncFileItem, instruction and status).
2016-08-05 13:12:01 +03:00
if (isShared)
Refactor the overlay icon logic to show errors as a warning for parent folders #3634 This also remove all smartness from the SocketApi about the status of a file and solely use info from the current and last sync. This simplifies the logic a lot and prevents any discrepancy between the status shown in the activity log and the one displayed on the overlay icon of a file. The main benefit of the additional simplicity is that we are able to push all new status of a file reliably (including warnings for parent folders) to properly update the icon on overlay implementations that don't allow us invalidating the status cache, like on OS X. Both errors and warning from the last sync are now kept in a set, which is used to also affect parent folders of an error. To make sure that errors don't become warning icons on a second sync, SyncFileItem::_hasBlacklistEntry is also interpreted as an error. This also renames StatusIgnore to StatusWarning to match this semantic. SyncEngine::aboutToPropagate is used in favor of SyncEngine::syncItemDiscovered since the latter is emitted before file permission warnings are set on the SyncFileItem. SyncEngine::finished is not used since we have all the needed information in SyncEngine::itemCompleted.
2016-03-24 19:42:04 +03:00
status.setSharedWithMe(true);
return status;
}
void SyncFileStatusTracker::invalidateParentPaths(const QString& path)
{
QStringList splitPath = path.split('/', QString::SkipEmptyParts);
for (int i = 0; i < splitPath.size(); ++i) {
SyncFileStatusTracker: Fix compilation with older Qt
2016-03-30 14:41:44 +03:00
QString parentPath = QStringList(splitPath.mid(0, i)).join(QLatin1String("/"));
[shell/windows] Fix the windows status push not working (#4784) Since the windows implementation first does cache lookups using the path string, directories need to be passed identically as through RETRIEVE_FILE_STATUS. Change the convention to never have a trailing slash for directories in the protocol. This allows the convention to be applied without having to access the disk (since we'd need to know if the path is represented by a directory) and also matches the convention of the rest of the sync engine. Individual file manager plugins are then responsible of handling pushed paths as not ending with a trailing slash. This also: - Moves the trailing slash removal logic from the SyncFileStatusTracker to the SocketApi class - Remove the unneeded QString::normalized call in fileStatus, since this should already be done by the FolderWatcher and plugins
2016-05-06 13:32:01 +03:00
emit fileStatusChanged(getSystemDestination(parentPath), fileStatus(parentPath));
Refactor the overlay icon logic to show errors as a warning for parent folders #3634 This also remove all smartness from the SocketApi about the status of a file and solely use info from the current and last sync. This simplifies the logic a lot and prevents any discrepancy between the status shown in the activity log and the one displayed on the overlay icon of a file. The main benefit of the additional simplicity is that we are able to push all new status of a file reliably (including warnings for parent folders) to properly update the icon on overlay implementations that don't allow us invalidating the status cache, like on OS X. Both errors and warning from the last sync are now kept in a set, which is used to also affect parent folders of an error. To make sure that errors don't become warning icons on a second sync, SyncFileItem::_hasBlacklistEntry is also interpreted as an error. This also renames StatusIgnore to StatusWarning to match this semantic. SyncEngine::aboutToPropagate is used in favor of SyncEngine::syncItemDiscovered since the latter is emitted before file permission warnings are set on the SyncFileItem. SyncEngine::finished is not used since we have all the needed information in SyncEngine::itemCompleted.
2016-03-24 19:42:04 +03:00
}
Move the SocketApi business logic to a libsync SyncFileStatusTracker class This will allow testing this code and avoid going through too many layers to get notified and a file status changed.
2016-03-17 14:26:44 +03:00
}
[shell/windows] Fix the windows status push not working (#4784) Since the windows implementation first does cache lookups using the path string, directories need to be passed identically as through RETRIEVE_FILE_STATUS. Change the convention to never have a trailing slash for directories in the protocol. This allows the convention to be applied without having to access the disk (since we'd need to know if the path is represented by a directory) and also matches the convention of the rest of the sync engine. Individual file manager plugins are then responsible of handling pushed paths as not ending with a trailing slash. This also: - Moves the trailing slash removal logic from the SyncFileStatusTracker to the SocketApi class - Remove the unneeded QString::normalized call in fileStatus, since this should already be done by the FolderWatcher and plugins
2016-05-06 13:32:01 +03:00
QString SyncFileStatusTracker::getSystemDestination(const QString& relativePath)
Move the SyncFileStatusTracker directory slash suffix logic in a method
2016-03-29 18:55:02 +03:00
{
[shell/windows] Fix the windows status push not working (#4784) Since the windows implementation first does cache lookups using the path string, directories need to be passed identically as through RETRIEVE_FILE_STATUS. Change the convention to never have a trailing slash for directories in the protocol. This allows the convention to be applied without having to access the disk (since we'd need to know if the path is represented by a directory) and also matches the convention of the rest of the sync engine. Individual file manager plugins are then responsible of handling pushed paths as not ending with a trailing slash. This also: - Moves the trailing slash removal logic from the SyncFileStatusTracker to the SocketApi class - Remove the unneeded QString::normalized call in fileStatus, since this should already be done by the FolderWatcher and plugins
2016-05-06 13:32:01 +03:00
QString systemPath = _syncEngine->localPath() + relativePath;
// SyncEngine::localPath() has a trailing slash, make sure to remove it if the
// destination is empty.
if( systemPath.endsWith(QLatin1Char('/')) ) {
systemPath.truncate(systemPath.length()-1);
Move the SyncFileStatusTracker directory slash suffix logic in a method
2016-03-29 18:55:02 +03:00
}
[shell/windows] Fix the windows status push not working (#4784) Since the windows implementation first does cache lookups using the path string, directories need to be passed identically as through RETRIEVE_FILE_STATUS. Change the convention to never have a trailing slash for directories in the protocol. This allows the convention to be applied without having to access the disk (since we'd need to know if the path is represented by a directory) and also matches the convention of the rest of the sync engine. Individual file manager plugins are then responsible of handling pushed paths as not ending with a trailing slash. This also: - Moves the trailing slash removal logic from the SyncFileStatusTracker to the SocketApi class - Remove the unneeded QString::normalized call in fileStatus, since this should already be done by the FolderWatcher and plugins
2016-05-06 13:32:01 +03:00
return systemPath;
Move the SyncFileStatusTracker directory slash suffix logic in a method
2016-03-29 18:55:02 +03:00
}
Move the SocketApi business logic to a libsync SyncFileStatusTracker class This will allow testing this code and avoid going through too many layers to get notified and a file status changed.
2016-03-17 14:26:44 +03:00
}
Reference in a new issue Copy permalink