Does odrive add any metadata to files or change them in any way once synced?

Hi there. I’m having a strange issue where suddenly files that I’ve had running fine in odrive before are suddenly running strangely. I’m wondering if something has changed recently or if some sort of ‘meta’ is being written into the files once they’ve been synced. I’ve tried unsync and syncing again but they still are running strangely. I’m using an image editing app and any files that were created in odrive react very slowly in the app, even if I’ve copied them locally. Other folders on my computer with images that never lived in odrive are running fine.

Thanks in advance. I’m on a MacBook M1 with latest version of Big Sur. This problem seemed to begin after I used this Mac to migrate to an older Mac I have as well using apple migration so I suspect it’s something to do with that, though it’s odd that the Mac that was used to sync from would be affected.

Thanks in advance

Hi @jhinden,
odrive doesn’t manipulate the files in any way unless they are being encrypted, in which case the only change is that encryption is applied to the file data and name on upload and then unencrypted on download.

To clarify:
These files open slowly in your app after being downloaded and then opened inside an odrive folder?
If you copy the same file out to another location, like your Desktop, these files still open slowly?
What storage are you using?

Can you try the following tests to see what the behavior is?
Test #1

  1. Take a file that is currently behaving the way you expect (opens quickly?) and then copy it into odrive.
  2. After the file has uploaded, open the copied file from its new location in odrive. Is the behavior changed?
  3. Unsync the file, sync it again, and then open it. What is the behavior this time?

Test #2

  1. Take a file that is currently behaving the way you expect and upload it to the storage service not using odrive (if this is possible using the native webapp for the storage, for example).
  2. Sync that file down in odrive and open it. What is the behavior?
  3. Download the file using the storage’s web app and open it. What is the behavior?

Thanks Tony, will give that a shot shortly. On a side note, I’ve noticed that ‘oDrive’ app in ‘get info’ says version 0.0.0 (seems odd) and is ‘intel’ (which I’m guessing is normal and app just uses rosetta). The installer I downloaded this morning says : odrivesync.6997

Test 1 -
Worked fine until step #3. When I unsynced the file I got an error message:
"Can’t unsync /[filepath] and ‘can’t find the specified path.’
Then, the .cloud versions appeared and I was able to sync them back.
Those files were also fine (fast load).

Test 2 -
Also works fine.

So strange. Things were working fine days ago and until I did a migration to clone my machine to a new computer.

I’ve done another test which is to move those files to the desktop and they’re also working fine.

Seems to me like there is an issue with some corruption on the files I had in odrive before I did something with MacOS migration to the new machine. Really strange. There is also the possibility that the app I’m using is the culprit. I just can’t sort out why it would load images fast from one folder, but not another suddenly.

Hey @jhinden,
Thanks for running those tests. What you are seeing is definitely strange, but it doesn’t seem like odrive is the culprit.

The unsync error is odd too, and may point to something strange going on with your drive, as you said. Have you tried running “First Aid” on the disk using the “Disk Utility” app yet, to see if it find/corrects anything unusual?

As for the odrive version, you can always tell what version is running by looking at the odrive tray menu at the bottom. The .app is just a launcher so it isn’t versioned.

Ok thanks Tony. The odd part is it’s happening on two machines. Will try disk utility thanks. Will have to give it a think and if it’s odrive related in the end, I’ll post back here again.

1 Like

Just a follow up question here as I’ve been doing some testing.
Does ‘odrive’ or the ‘os’ embed image preview thumbnails? I’ve noticed that if I reexport the images using an image editor and examine the image meta there is no embedded thumbnail and the images stream much faster. I’m wondering if perhaps the OS or oDrive has done something with embedded thumbnails to the images that went wrong or was unnecessary. Thanks

Hi @jhinden,
odrive will write the data to the local disk exactly as it receives it from the cloud storage. It very purposefully does not change anything about the file. It basically opens the file for reading and then sends the read bytes to the remote storage. Similarly on download it will request the file and then stream the bytes to the local disk. The remote and local files should always be a bit-for-bit duplicates.

I am not aware of MacOS adding embedded preview images, but I don’t know for sure.

Could there be another application that is doing it? Perhaps an app that you use to manage your images?
Where do these images originate from?

Ok, thanks Tony. I figured that was the case. Unfortunately I’m at a loss for figuring out what has happened.

The images originated from Adobe Stock, then Google Drive and I just checked by downloading from Adobe directly and they show up in my exif meta viewer as having an embedded thumbnail. Whether its the OS doing that after downloading the image or the meta is actually there to begin with I’m not sure.

And I’m not sure it’s even part of the problem. Strange one…several days ago everything was fine and suddenly I’m having the same issue on two machines. I know I’m not crazy because I just did a project recently that opened and played back smoothly with no issues and now I can’t get it (or a new project) to do the same on either computer. They both were running odrive so I figured that was a good place to start troubleshooting.

In any case, it seems that it’s not an issue with oDrive so I just wanted to rule that out. Thanks for your time. I’ll try to figure it out from here.

1 Like

No problem @jhinden!
I hope you are able to figure it out.

Is it possible that the editor you are using changed and now is exhibiting different behavior than it was before when opening these files?