This is inspired largely by the new (/ returning) feature of OneDrive in Windows 10 Fall Creator's Update, which downloads files on-demand.
A side effect of that change is that the OneDrive folder (and subfolders of it) are marked as reparse points, even though they are not technically standard symlinks.
With this change, a new extension method IsSymlink is added for ISnapshotService and ISystemIO, which checks both the file attributes (for reparse point) and the symlink target path (if null, the path is not treated as a symlink).
All places that previously checked only the file attributes have been updated to use either this method (or at least the same logic, in the case of the core BackupHandler file check).
One side effect of this change is that '--symlink-policy=store' no longer ignores empty symlinks - they are now treated as regular files.
If there are empty symlinks, they will now be backed up as if they were regular files, but I don't know what the conditions are that create symlinks like that, so this might not effect anything in practice.
It also makes quota enabled backends return an instance of this interface instead of the quota components separately.
This way, getting quota stats requires only a single remote request on backends like Google Drive and OneDrive.
- Don't use Vacuum() just before PurgeLogData (which performs vacuum() already)
- Removed unncessary poorly performning query (after optimizing it I found out it's unused)
- Correctly log calls for ExecuteScalarInt64
Now we only look at the timestamp from the previous fileset, instead of for the last time the file was seen.
This should improve lookup times, and thus the running time for backups with many files.
This change means that the following sequence of operations will react differently:
- backup
- delete file
- backup
- undelete file
- backup
Prior to this commit, the undeleted file would be seen with the original timestamp and thus can avoid being scanned for changes.
After this commit, the file will be treated as a new file, even if it has the previous timestamp and will thus be scanned for changes.
An additional switch has been introduced, --check-filetime-only that improves the lookup further by not looking at the metadata or filesize, and thus makes a much lighter call to the database, where fewer tables need to be touched.
Added correct handling of metadata hashes, such that a metadata blockset is now handled the same was as a regular file blockset.
The query that creates the filesets does not support more than a single blocklist of metadata, hence the limitiation.
Kenneth Skovhede