As I always start off, thank you for a great product! I am still passing on the good words about odrive to friends and coworkers. Even better, I realize it has been quite a while since my last new question. (Still waiting for the backup feature…by this point it must be frustrating you all as well as us).
It would really be helpful when trying to open files that have been ghosted (replaced with .cloud) if odrive would recognize the request and sync the file so it can continue to open. Far too often I try to open a recent file via the Start menu or Recents folder only to be receive:
Note Windows doesn’t provide a convenient “Open file location.” It’s not the end of the world, but it is disruptive to have to open Windows File Explorer, track down the directory, then double click on the file.
On a separate note, thank goodness .cloudf files no longer appear in my drives! Can’t remember if that was a setting or update, but thank you!
Hi @Chris.D,
Thanks for using odrive! I’m glad to hear you are enjoying it.
As for the issue above, unfortunately I don’t think there is anything we can do about this behavior. The problem is that Windows cannot associate a .cloud file with a non-cloud file. When you see the file listed, it is a reference to the non-cloud file, so when you click on it Windows tries to open it at that specific path. Since the file is now unsynced and has the .cloud extension, Windows won’t find it. It also won’t communicate any of this to odrive, so odrive is fully unaware of the whole process.
.cloudf files are still around, but they are only seen on unsynced folders. If you have expanded all of your cloud folders, then you won’t see any .cloudf files. If you right-click->unsync a folder, you will see that it turns into a .cloudf placeholder.
Thanks, Toni. I wonder if there are other ways to think about this.
Is there a way to associate file types (e.g., *.docx or *.docx.cloud in the case of sample.docx) that are turned into .cloud files (e.g., sample.docx.cloud) with odrive such that “on error” or as an alternate program if the file is not found? So MS Word would look for the .docx file to open it, but the Windows registry or startup program would capture the error and then if that same filename+.cloud is found, it would launch odrive to sync the file first (perhaps along with a message box alerting the user) and then have Word continue loading the file.
Hi @Chris.D,
Unfortunately I don’t know of a way to do that. When an application tries to open a file, directly, it usually tries to open it with its own open routine. The application that does the initial opening (Word, in this case), would need to be programmed to understand that fallback behavior.
I think what you are looking for is more along the lines of what Google Drive File Stream and ExpanDrive offers. Basically all your files in the cloud are treated exactly as the file type it is even though the data associated with the file has not been download to the system. In essence, you are looking at file placeholders but the difference between odrives unsync feature and File Streams sync on demand is you will still see a docx or pdf or whatever file type and the cloud drive will just stream the files to the system as you open them.
I do think File Stream on demand cloud storage is a much better idea than the cloudf unsync files implementation that odrive uses. Maybe @Tony might want to look at that cloud sync model for a future version of odrive.
I do think there is one limitation to the sync on demand and that is too many api requests to your cloud storage provider in particular google drive. If you have some demanding application like a torrent app constantly hitting the cloud drive to download a file or lots of files all the time then you could potentially run into those cloud storage 24 hour bans where you can no longer download your data. This would be a good reason why Odrive’s cloudf unsync makes sense. When you sync a cloudf file to your local drive, it is there for good. You can use whatever app you want to open and close the file as many times as you want because the full file is local to your system. The only time you would need to communicate with the cloud storage again is when the file changes.
So in closing, sync on demand makes sense when you have files you want to edit but you do not want the data taking up space on your local filesystem but you want them to still be as accessible as a local file. If you have more demanding uses of a file where you will be opening and closing the file a lot or making frequent changes to the file for long amount of time then you are going to want your full data synced locally the way odrive currently works.
In one our first product incarnations we had this type of concept using a virtual filesystem driver. At the time we ended up having a number of user issues because of confusion with what was locally cached on the disk (even with visual indicators) and what wasn’t, because the files look exactly the same with the same extensions. It also required a low-level filter driver to be in the mix, which adds a good deal of complexity.
In our case it was probably introduced prematurely, when users weren’t really ready for it. Its an idea we’ve considered revisiting because the general understanding of virtual files has increased, along with the technology. We don’t have any definite plans yet, though.
