Jon B.1 Collaborator | Level 8

I've opened a ticket (Ticket #24206378) and am waiting for followup!

Yes, 14.6.1, and the Dropbox client was tried with a couple of different versions (including upgrading to FileProvider).

Hello Andrew! Ran the test program on a 4K XML file, which exists and is readable on the website, but shows up as 0 bytes in Finder. It reported the error "File size is zero bytes. Nothing to be downloaded" -- so it doesn't get as far as attempting to read the file. When I comment out the return in that clause of the test…

We can do that in this case, but if possible we'd rather not force all Mac users to sync everything locally, so it would be better to automate it! Thanks, though.

Updates at last! I can confirm that turning off syncing avoids the problem. And the problem is still only appearing on one macOS machine. Here's the events log and a Version History for the (failed, deleted and now restored) "Level 2A - Encrypted" folder, from a new test run:…

Sigh. Disregard last two comments; both failures were still on the same macOS machine. (There was a separate failure on the Windows machine, not a conflicted copy.)

* universal

We'll try that! FWIW, we've now seen the problem on a second machine (a macOS one), so this isn't down to an individual machine's configuration. OTOH, we've seen this work successfully on a bunch of other machines with no problems, so it's not univeral.

Further addition -- here's the folder activity on the restored just-plain-Level-3A folder. Since there are multiple deleted-and-added files with those names in the event log, I can't immediately find which one I should restore and check its version history -- can you recommend a way to work that out? Or should I just get…

Oh, and a footnote -- the only difference between the two runs is the name and number of files. The successful run had two tiny text files in each folder, the failed one had three large files in the megabyte range in each one. That suggests a timing issue in how long it takes to re-encrypt and upload... but we still get…

Hello Nancy! Here's an explanation and Events logs from two recent runs -- one successful, one failed. Both done on the same machine, the only one connected to that Dropbox account, so there's no interference from outside. (Every other machine and account we've tested with has consistently been working fine.) The Events…

Hi Walter! Here's some updates. First of all, I'd like to point out that the problem appears to be timing-related -- we see it regularly on this one machine when encrypting/decrypting a large structure of folder and files in the multi-megabyte range. When doing it with a small structure with only a couple of text files,…

Further update: the FileProvider fix in 9.2.0 appears to be specific to iOS mobile devices -- this is a desktop macOS FileProvider, so not relevant to us. So thanks -- this is a non-issue!

Update on this: I think the infinite number of Dropbox warnings were down to startup issues -- the FileProvider extension was trying to get basic Dropbox details (including the local path) before checking whether the main app was up and running yet, so it would keep reiterating the warning while the main app was still…

So do a complete recursive directory listing at the same time as the initial find, and then just track the updates and filter them for files which match... yeah, that's doable! Thanks.

Footnote: for the record, I mean search V2, not V1!

Thanks -- I think it would be a very useful feature to add! Re the Data object -- is there a recommended maximum size for this kind of download, like the way uploads greater than 150Mb should be done as a session? This will determine whether we try the Data approach and feed it through a stream, or stick with a file…

Thanks -- I'll pursue this with Apple! If I get a sensible answer, I'll report it here.

Just want to confirm that upgrading to 8.2.1 fixed the main problem! There were additional issues with the downloaded temp files not saving and opening successfully, but those were down to a quirk of the Apple FileProvider -- it was making a "file modified" call to update a "file last used" field immediately upon opening,…

Turns out I've been building against an old version (6.0.3); I'll upgrade to 8.2.1 and get back to you! For what it's worth, the download code is fairly basic at this point: logger.log("dbx_downloadWithProgress: Downloading" + filePath) let destination: (URL, HTTPURLResponse) -> URL = { temporaryURL, response in return…

Further details on this: I know the app group is working; I've been able to access the app group's folder under Group Containers from both the main app and the extension. Whether I have the transport client set up with the group ID or not, download requests from the main app succeed *until* the extension is initialised. It…

I think I've resolved it -- I'm still not sure why it was interfering with that URL scheme in the main program, but that may be down to the Group Container settings which lump the app and the Finder Sync extension together for communication purposes! The source of the problem was that the Finder Sync extension was trying…

Here's a bit more on this. The problem seems to be a timeout that's causing the application to sit for up to one minute between me pressing "Allow Safari to open [my app]" after pressing the Allow button during the auth process, and the event actually being received in my code. As far as I can tell, there doesn't appear to…

Just to confirm, though: I'm aware that authorizedClient maintains and refreshes the same tokens while the app is running. But you're saying that if I quit and relaunch the app, authorizedClient persists the tokens and is still valid by default? If so, I'm a very happy man...

Brilliant! Nice to know I was overthinking things...

Following from my previous update -- this is SwiftyDropbox 6.0.3 installed using CocoaPods, and Xcode 12.5 on Big Sur 11.4. But as I said, I'm now suspecting that there's something going on elsewhere in my app, blocking the dispatch queue which authorizeFromControllerV2 / handleRedirectURL is trying to use. Are there…

Update on this: turns out the completion handler *was* running consistently, it just took about two minutes to do so, and so other things were timing out as a result! It looks like something is sitting on the main thread in my app, which was blocking the completion handler from running. I'm still investigating. Basically,…

Further update: this behavior is visible through the HTTP endpoints as well, using the API Explorer, so it's not a Swift problem. It would appear to be a server-side bug in regular-expression handling. Note that searching for "\.empfs1.xml" does find .empfs1.xml -- and also empfs1.xml (without the dot) and new.empfs1.xml.…

I've just brought a VM (running Windows Server 2008 R2, SP1) out of mothballs, last used this past November. At the time it was running v14 of Dropbox.exe, but now this brings up an "update to the newest version" pop-up, and automatically upgrades it to the current version (v32.4.23.0). At which point it crashes, and from…

Further notes on this, for anyone's reference : In the registry, HKEY_CLASSES_ROOT\*\shellex\ContextMenuHandlers\DropboxExt contains the handler ID {ECD97DE5-3C8F-4ACB-AEEE-CCAB78F7711C}. There's a similar value under HKEY_CLASSES_ROOT\Directory\shellex\ContextMenuHandlers\DropboxExt . Under…