I use Microsoft Outlook from two computers. The main .PST file holding the mail|contacts etc is stored on an amazon drive via an Odrive folder. The file is 2.5GB and I have large files split to 2GB. All works ok. However, when looking into the amazon storage I see many .xlarge folders, all empty, and they never get deleted. This causes the odrive desktop show that the folder containing the .PST file is always syncing. Even if Outlook is closed for a long period to let the .PST complete sync, which it does do, the odrive still show sync happening. When I manually delete the .xlarge empty folders, the odrive sync stops.
Is this normal? Shouldn’t the empty xlarge folders be automatically deleted so that the sync will show done instead of the false indication that it is still syncing?
Hi @stewart.bodzin,
Thanks. I think I know what is happening here.
If you are syncing an actively used pst file then it will be constantly changing. Each time the file changes, odrive will try to sync those changes up. Since the the file content keeps changing, odrive will abort the upload in progress, wait, then reattempt. Each time it is aborted it will leave the aborted xlarge folder around.
Leaving around the aborted xlarge upload is something we will need to address (I have spoken to the product team about this), however, it is strongly recommended that you so not sync actively used pst files. Since these are essentially database files, and change constantly, you end up having odrive continually trying to upload these files, which can waste a lot of processing power and bandwidth in the process.
Hey, you hit the nail on the head. Your analysis matches my own suspicions of the cause of the symptoms. However, one of the incentives for me to purchase the Odrive software was to support allowing me to switch computers using outlook at various times. I realized that I would have to exit outlook on one machine and allow the sync to complete before using outlook on another machine.
The expected behavior that I was anticipating was that Odrive would NOT sync an open file. If the file was open, the sync would ignore it until the file was closed. Once closed, the sync could start. If the sync did not complete due to the file being opened again, then the sync would abort and cleanup the residual .xlarge folders. This solution is much more robust and would be a great advantage in functionality supporting a single serially accessed file and as a key feature for your Odrive product. I would be happy to beta test this functionality if you were to pursue it.
Just allowing me to do a backup of the .pst file is no solution at all. A principal power of Odrive is the ability to automatically execute a policy for a synchronization. If you would like me to elaborate further on a possible fix, let me know. You guys have built a fabulous product, but the above description identifies a significant flaw.
These are ideas we have actually pursued in the distant past, but have their own detriments. We found that many folks will not close an application that retains control over a file for days and days, so it will not sync at all. We try to strike a balance by monitoring file growth and waiting until the file is idle for a certain period of time before attempting sync, but certain file types and applications are more prone to hitting this type of cycle, like Outlook and pst files.
There may be a better balance to strike and I have asked the product team to take a look at this thread. In the meantime you can try to work around this by stopping sync and then starting it once you are ready to sync your changes.
Thank you for the update. A simple solution is to mark a specific file, via a right click menu selection, to specify that the file should not start sync operations until it can be opened exclusively by Odrive. That way, once the sync starts, it will complete and block the user from opening the file; UNLESS the user clicks again on the file to abort/stop the sync. This would work for me and would allow any size database to be supported. One could open a very large database for a project, perhaps for days, and once closed, know that it would be synced. Just my two cents. Thanks for forwarding the thread to your development team.
