[RobNY]

Here's the situation:

- Primary device is an iPad.  I have a library called "Primary".   This library is sync'ed to a google drive folder called "MS-PRIMARY".
- When I look at this google drive folder, I see two sub-folders:  "stamps" and "primary".   "Stamps" is empty; "primary" has the DB and PDFs.... all good.

I have second iPad with a library called "Primary".  When I want to sync, I simply point it to the same google drive folder ("MS-PRIMARY") and it works fine.

However, on my MAC (new M4), I created a library called "Primary", and tried to sync it to the same folder and it tells me it is empty and prompts me to seed it with the device (mac) data.  

But, if instead of pointing the mac to sync on "MS-PRIMARY" I instead point it to "MS-PRIMARY/primary", then it works.

Either I have a setting wrong somewhere or the behavior on iOS is different from how the app performs on a Mac. The iPad's seem to know to look for a library directory under the google drive directory -- but the mac does not.

Any insight?

[Zubersoft]

I've been flip-flopping on how I want to store the data for a library synchronized to a cloud folder. When I changed the library behavior with 3.9.18, I wanted to keep every library in a different cloud folder subdirectory if storage isolation was enabled. However, this turned out to be a bad idea, and just creates conflicts as users don't often know whether to pick the subdirectory or the main folder. So I've reverted back to using the selected folder as the destination for the files regardless of what library is active (it will be up to users to pick appropriate folders to synchronize to based on what library is active). However, I didn't want to mess up user's cloud synchronizations that may have happened after 3.9.18, so the logic was changed to look for a library in the current folder, if one exists, use that, if not, look for a subdirectory if using a library with isolated storage, and if that is found, use that instead. So if you can, just get rid of the subdirectory, and sync directly to whatever folder you want to use, as subdirectories are no longer created with 3.9.25 onward.

Mike

[RobNY]

I've been flip-flopping on how I want to store the data for a library synchronized to a cloud folder. When I changed the library behavior with 3.9.18, I wanted to keep every library in a different cloud folder subdirectory if storage isolation was enabled. However, this turned out to be a bad idea, and just creates conflicts as users don't often know whether to pick the subdirectory or the main folder. So I've reverted back to using the selected folder as the destination for the files regardless of what library is active (it will be up to users to pick appropriate folders to synchronize to based on what library is active). However, I didn't want to mess up user's cloud synchronizations that may have happened after 3.9.18, so the logic was changed to look for a library in the current folder, if one exists, use that, if not, look for a subdirectory if using a library with isolated storage, and if that is found, use that instead. So if you can, just get rid of the subdirectory, and sync directly to whatever folder you want to use, as subdirectories are no longer created with 3.9.25 onward.

Mike

I'm not sure I completely follow this, but here's what I did learn -- all of the devices are running .26.

1. If "store library in separate directory" is checked, then outbound/update-folder sync absolutely still creates a subdirectory in the sync destination folder.
2. If, in other MS instances, you have a library created that also has this flag, sync works fine -- it will look for a subdirectory in the sync folder.
3. If, in other MS instances, you have a library that does NOT have this attribute, then MS will not look for a subdirectory and you will either get the "empty" message, or you need to explicitly specify the subdirectory.

#3 was my issue as the one instance (on the Mac) did not have the "store separately" flag checked.

This actually makes complete sense when you think about it.  My only comment might be that it should be noted that creating a library in a separate location also impacts how SYNC works -- and rightly so.

Your comment "...as subdirectories are no longer created with 3.9.25 onward" -- is that correct since outbound sync DOES still create a directory if "store separate" is checked?

[Zubersoft]

It does look like a folder is still being created at the moment. That's not really what I want though, so I'll have to make further changes.

Mike