Hi @Tony- I am now having other issues similar to my previous thread regarding Yandex that I can’t pinpoint very well, but seem to be similar (at least from a UX point of view):
After adding a number of new sources through the web interface, the .cloudf links for them were not appearing in my odrive root on either my desktop or laptop. Even after restarting both the client, and then the PC. I deauthed the account on my desktop, and they all showed up after re-authing. I haven’t done this on my laptop yet, so the issue is persisting in case there is anything I can do to help troubleshoot.
pCloud and CloudMe sources are not able to be synched on my desktop client (unsure about the laptop, as I do not have the placeholders for them to attempt it yet). At first I thought it was a WebDAV-related thing, but then I added other WebDAV providers (PowerFolder and OpenDrive) and they worked just fine. This has persisted after a re-auth of the client as above. The client just shows this error:
After re-authing my desktop client, attempting to sync my one and only Encryptor folder worked seamlessly - it did not prompt for a passphrase. This seems to indicate there was some cache/storage somewhere that odrive was able to keep this information, and it wasn’t cleared when the client was deauthed, as would be expected. Could this be related to the persisting issues above, in that some cache is causing issues?
Despite the above, for the folders that are synching, the client is perfectly responsive and doing exactly what is expected.
Hi @yukihyou,
For the missing links, is it possible that you were logged in as a different account on the odrive desktop client? This can happen pretty easily if you are linking lots of stuff and end up logging into odrive using a different account (Google vs Microsoft, for example). The odrive account is tied to the OAuth service used for logging in. This can be checked from the odrive menu under “Authorized User” it should match what you see in https://www.odrive.com/account/profile
For pcloud I have seen a issue on Windows machines dealing with timezones on a few services. Its a weird aberration in Windows when calculating the date. A way to work around this is to do the following:
Temporarily change your Windows machine time zone to UTC-08:00 Pacific Time (US & Canada), Exit and re-launch odrive app and then try to expand the pcloud placeholder folder.
You can change your time zone back to its original state after expanding pcloud folder and it should start working from there without need to change time zone in future.
If that doesn’t work can you send a diagnostic from the odrive menu?
I only have the one account, and can definitely see the same list of all the other providers.
Changing the time zone didn’t seem to make a difference, the pCloud and CloudMe providers still gave the same Unspecified Error.
I’ve sent a diagnostic from this client (PC Name: Jaguar) just now.
EDIT: Have also now sent one from the laptop (Ultrakitteh) - as you can see below, it has a bunch of providers working, and they synch just fine, but there’s no placeholders for the missing ones.
(Note that the FTP placeholder here was created manually as referred to in the other thread, and both didn’t appear manually, and gives the proxy error when used)
Hi @yukihyou,
I took a look and pcloud and CloudMe as throwing that timezone-related exception mentioned above. temporarily changing the timezone and relaunching should work to allow you to expand those folders, but it sounds like it didn’t in this case. I will need to see if there is something else that can be done there.
The FTP link is throwing a socket timeout error: “A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond”
For the missing placeholders, it is generally a refresh delay, but a restart of odrive should definitely pick them up. Also, right-clicking on the root odrive folder and selecting the odrive “refresh” should query the service for new links and they should show up, as well. I’m not sure why they wouldn’t show up at all, unless they are named with a character that Windows can’t use in a file/folder name.
Thanks for your response in PM regarding this, it appears to be a server misconfiguration that odrive isn’t silently fixing as the other providers seem to.
I have definitely tried restarting both the client and the machine, as well as a root folder “Right-click → Refresh” and neither seems to have worked. If I create an empty placeholder file manually, it will work just fine. Additionally, this only seems to be happening on one PC. Is there anything else I can try to help troubleshoot why this might be occuring?
This installer fails every time:
The relevant part of the logs seems to be:
[C7F0:10314][2017-11-04T08:47:01]i000: Setting string variable 'WixBundleLastUsedSource' to value 'D:\Downloads\'
[C7F0:F534][2017-11-04T08:47:01]e000: Error 0x80070570: Failed to extract all files from container, erf: 1:4:0
[C7F0:10314][2017-11-04T08:47:01]e000: Error 0x80070570: Failed to begin and wait for operation.
[C7F0:10314][2017-11-04T08:47:01]e000: Error 0x80070570: Failed to extract payload: a4 from container: WixAttachedContainer
[C7F0:10314][2017-11-04T08:47:01]e312: Failed to extract payloads from container: WixAttachedContainer to working path: C:\Users\YukiHyou\AppData\Local\Temp\{C487DC11-63AC-4F37-8520-3ECFE13C1AA1}\01A14BEE51EAF3564BBBEBC7369884D631CA7E3D, error: 0x80070570.
[C7F0:E528][2017-11-04T08:47:01]e000: Error 0x80070570: Failed while caching, aborting execution.
The actual folder name under Temp (the GUID and the following text) appears to be generated differently each time. The contents of this folder are always the same though:
Once I click Close on the installer, the subfolders are removed but the cab... file remains. Running the installer again simply creates a new GUID folder with the same effects.
Thanks heaps for your help and patience with this.
Hmm… yeah its an odd one. If you can try to repro again and send a diagnostic after waiting a few minutes and trying a right-click->refresh on the odrive folder, I can see if there is anything odd showing up.
Another oddity. I downloaded the installer from the share and installed on a couple machines without any problems. If you haven’t already, can you try downloading again? A right-click->properties on the file should show the size as 76,223,688 bytes
The laptop is still exhibiting this problem, and has been since the original report. I don’t use any of the storage other than my Dropbox (which I’m in the process of migrating away from) on that laptop so I haven’t manually fixed this. I have just confirmed it is still happening, restarted, and will force a refresh and send a diagnostic once it’s back up (Computer name: Ultrakitteh).
That’ll do it. The file I got was was only 24Mb. I have now tried to re-download it a few times, and ended up with four different sizes - probably my internet being stupid, I apologise. I finally got one that is now the size you quoted, with SHA1: DB41266557643AE5749C25FFE5BC79F799876AB5, and it seemed to install ok.
I can confirm whatever you did, has worked! I can now just right-click Sync on both CloudMe and pCloud and they expanded just fine! One issue solved!
Edit: I’ve removed CloudMe and pCloud from my odrive providers now anyway, and will likely not use them at all going forward. Will be able to make do with multiple of other providers instead.
So, after some reorganisation of my providers (renaming all of them), the laptop has started to synch them down just fine. I sent another diagnostic to hopefully see what it was that triggered it to start updating correctly!
In regards to the testing on my desktop though, I noticed another unexpected behavior after installing the build of odrive you provided: It removed the “sync with odrive” partnership I had set up. This particular partnership links a logs file from an application between my laptop and my desktop - it is only ever in use on one (whichever I’m using) at a time (see note below).
When I noticed the synch was broken (I launched the app on my desktop for the first time in a couple of days, and the recent logs from the laptop were not present), I went into the folder that should be synched, did “sync with odrive” and pointed it back where it was supposed to be.
Expected outcome: Each file in the freshly-synched desktop folder updated to the latest version, as provided by the laptop into the cloud (there was no files modified by the desktop)
Actual outcome: The version in the desktop folder was considered the up to date version, and overwrote newer files in the cloud, which then synched down onto the laptop and overwrote them there
As the backing provider (Box.com) does not have version restore capability (at least, not in the free version), I am unable to restore these files at all. Luckily, this is not a critical loss, as there was little activity in those logs that are now irretrievable, however I am now very skeptical of using the “sync with odrive” function for anything. At the very least, I will be ensuring any folder I use it with is placed in a provider such as Dropbox where there is simple options for version restore to undo this mess.
*Note: This folder is “synched with odrive” on both the laptop and the desktop, from a folder in %APPDATA% to a cloud folder on Box. The idea being that if a file is updated on one PC, it will push to the other via the cloud, and the cloud should have the updated view of all files both ways - as long as the application is not modifying the same files at the same time on both ends (which it won’t - only one instance will be running at a time).
Hi @yukihyou,
Strange. I’m sorry to hear you ran into that issue with the “sync to odrive” relationship being lost. The new build only changed the way webdav integration functions, so it shouldn’t have removed any relationships. The relationship is stored in a local database in the .odrive folder in the user profile directory. The only thing that should affect that is an uninstall or some sort of external modification to the files in that folder, so I’m not sure what happened there.
“Sync to odrive” will not follow any local folder renames or moves. I have seen cases where a user renamed or moved the local folder in the “sync to odrive” relationship. When that happens the relationship is lost and the newly renamed/moved folder is no longer “seen” by odrive. If this does happen, however, the “old” folder should still be listed in the odrive menu under “sync to odrive”.
When using “sync to odrive”, you will need to keep in mind that the local system will be considered the “newest” source if there are file differences between the cloud and the local system when the relationship is created, even if the dates on the files are older. So, if sync to odrive was enabled (or re-enabled) on a local folder and the files differed from what it on the remote, odrive will assume that the user’s intent was to upload the local files to the remote storage. We’ve talked about creating more customization where you can specify which side should be the authoritative source in cases like these, where there are files differences, which would’ve been helpful for your use case.
I took a look at the diagnostic, but I don’t see anything abnormal. I suppose this is expected though, since it is working properly ;). I’m still not sure what was causing the lack of refreshing in the previous case.
This was the key information I was missing, which caused odrive to behave in an unexpected way. I will bear this in mind for the future, but will likely ensure all of my “sync to odrive” folders are on a provider that supports version restore.
As for the failing to refresh - it appears that renaming the providers caused the client to resynch everything, and it is now working fine.Thanks for the help in this thread!
