-
Notifications
You must be signed in to change notification settings - Fork 131
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[feature/fp-series-4] File Provider improvements #253
Conversation
|
8Rename + Duplicate in files app not working as expected when the server in maintenance mode (likely in whole offline mode) Steps:
Tested with commit |
0bd0782
to
c47d51e
Compare
Update with commit c47d51e:
Still Reproducible: (1), (4), (5), (7), (8) Batched uploads: #224 |
(9)Check this steps out:
Current: app is stucked Commit: c47d51e |
- Updated BookmarkViewController for leaner OCConnection init - Streamline ClientItemCell UI update code
- Fix SwiftLint warning
- Use OCHTTPPipelineManager.setupPersistentPipelines to keep pipelines open for the lifetime of the process - Add missing completionHandler calls for OCCoreManager scheduleOfflineOperation calls (!)
- use of NSFileProtectionCompleteUntilFirstUserAuthentication in FileProvider - Renaming "Activity" tab to "Status" - drew and added new icon "status-flash" - Update to latest ios-sdk
@jesmrec Ready for QA:
This is a OS level bug. Copy and pasting of folders is as broken as folder duplication. But we can't detect and block it in this case, unfortunately: Please see the log excerpt in Appendix A to see the commands iOS sends to the File Provider.
Likely an issue with the previous OCCoreManager implementation dead-locking or OCCore locking on shutdown. Both known issues have been addressed. I could not reproduce this issue.
Cancellation is now only available for those sync actions that have support for it (currently upload and download), so issue 4 no longer applies.
The cancellation is stored as an event, but only processed when the operation's sync record's time has come. So if you upload a large file and then trigger a download, then cancel the download, then cancel the upload, the download will not take place. Improved cancellation support is part of the full implementation of offline support.
This should have been fixed for a while. FWIW I could not reproduce this.
This is also subject to implementing full offline support.
I could not reproduce this direc, but found another issue, which I fixed. The way it should work now is that an alert comes up saying that the file has changed on the server - and whether the user really wants to delete the file. That alert is triggered by the server responding with Appendix A
|
Checks with 77cd2c0 (1), (2), (3), (4), (6), (7), (9) -> fixed (8) -> addressed to offline About (4) and (5)
i guess you mean cancellation for enqueued operations, not for the current executing one. Apart of the technical explanation about the sync record (thanks!), the point is that the user should not see a "stop" button that is not clickable. So, i'd extend the non-availability condition for cancellations to every enqueued action, included uploads and downloads. We will iterate to improve this.
for me, this behaviour is the expected. you cancelled the enqueued action, so it will not take place after the current one finishes or is cancelled. |
…/ios-app into feature/fp-series-4
…nitions to OCCoreManager changes
Description
Further improvements to the file provider
Related Issue
Motivation and Context
How Has This Been Tested?
Screenshots (if appropriate):
Types of changes
Status check:
ios-app/ownCloudTests/Login/EditBookmarkTests.swift
Line 85 in efe24f4
BUGS & IMPROVEMENTS