Apple File Provider - Cloud Storage file paths not working properly with ArchiCAD Publisher

[Ebatte]

Anyone using a streaming cloud file storage service on MacOS such as Dropbox, Google Drive, One Drive, etc.? Of course you are. Welcome to the 21st century! In our case we use Google Drive, but the issue below would appear to apply to any modern cloud storage provider being used on MacOS.

Over a year ago Apple implemented a standardized way for cloud storage providers to hook into the operating system called “Apple File Provider”. This means that any cloud-based file storage system will now store streaming files in ~/Library/CloudStorage...

As you can see, this path is user dependent which creates a problem establishing a common publishing path for Publisher Sets. Formerly google drive was located in /Volumes/Google Drive. Now it is located in ~/Library/CloudStorage.

/Volumes/Google Drive could be set as a common path which was usable by anyone else in a Teamwork project, but once set using the new path it will obviously not be found by any other users.

Helpful tip for Google Drive users:

- Quit Google Drive for Desktop.

- Run this command in a terminal touch ~/Library/Application\ Support/Google/DriveFS/fp_left_beta

- Start Google Drive and log back in.

This will continue to use the former location for Google Drive and paths will work as they have in the past.

Source

There may be similar options for Dropbox, One Drive, etc. 

Will Apple "fix" it? Unlikely. This seems to be caused by Apple's implementation. 

Will Google "fix" it? Unlikely. They will point the finger at Apple. Same with all other cloud providers.

Can Graphisoft do anything to "fix" it? Unknown. They are just storing a file path in the project. If the path is broken, then what can they do about it?

Is there anything else we can do as users to fix broken paths like this? Unknown.

• I doubt if unix symbolic links, shortcuts, or anything like that would help. 
• You could publish to BIMcloud instead of the file system. This is not acceptable for me or our staff.

If anyone has any thoughts on this matter please discuss.

[Lee Hankins]

We have a Template configured that has no file paths for publishing defined. One of the first steps when setting up a new project file is to set this publishing file path to the job folder path on our Synology NAS which is accessed on the local network and over VPN. We’ve never had any issues with publishing from Teamwork or solo projects once this path is defined as it never (or vary rarely) changes. If the path is changed then Archicad just recreates the original path which in itself is a bit annoying because you don’t notice until you can’t find your published drawings and realise there are two project folders with ever so slightly different names. This is an internal management issue though. It would be better if Archicad provided an error rather than recreate the path. 

[Ebatte]

Right. Although, the issue you describe isn't related to the Apple File Provider framework since you're using a NAS.

[Lee Hankins]

No, granted, but it’s effectively the same thing. There’s no way the software could maintain a link to a location that is user specific. As you say it worked until Apple moved the folder to the user folder. I’m guessing there is no way to use a wildcard for the user so I matter what the user folder is called Archicad can still find the path within. 

[Ebatte]

The wildcard for the "user folder" is ~ (tilde).

Dropbox uses this as the path: ~/Library/CloudStorage/Dropbox

Google Drive uses: ~/Library/CloudStorage/GoogleDrive-eric@mgarchitects.com <<<---note my email address in the path. This makes it user specific and would break the path for other users. The way Dropbox does it would work for all users.

[Karl Ottenstein]

---

@Ebatte wrote:

Dropbox uses this as the path: ~/Library/CloudStorage/Dropbox

---

...and just to add OneDrive to the mix, it's now also at ~/Library/CloudStorage/OneDrive

[Ebatte]

Good to know, Karl.

I suggested to GS support via email that perhaps the AC developers could add variables to accommodate the non-confirming path(s) so that AC could "translate" them to UNC conforming paths.

Example:

AC Variable A: [GoogleDriveUsername]

Path: ~/Library/CloudStorage/GoogleDrive-[GoogleDriveUsername]

This would allow AC to store the path with the variable and each user would have their variable parameter substituted on demand.

[KenMcN]

Same problem here. We use SharePoint and OneDrive to share files. At the moment we have a local file server with folders that sync to SharePoint, but the Publisher path has to be set to the (local) shared drive. So you still have to connect to the file server (or NAS) using a VPN if out of the office. If you have to connect to the server anyway, the benefit of OneDrive is largely lost. 
I spoke to Graphisoft about this and they thought another firm had solved it, but never got back to me with any details. If you can mount the Sharepoint ‘drive’ on your computer it might work, but we use Macs and I can’t find a way to do this without it using the user name as part of the path, as you said Eric. 
The v26 launch suggested that remote working was going to be addressed. Sadly, this wasn’t part of their brief. 

[Ebatte]

So far the GS acceptable solution is to put all files in BIMcloud. That is actually not an acceptable solution because BIMcloud is not part of the filesystem as far as the OS is concerned. Files stored in BIMcloud have to be downloaded manually before they can be interacted with, and then uploaded again after modification. So, sure that's a place to store files, but now a place to use files.

In this scenario we have to manually replicate files at the OS filesystem level and at the BIMcloud level manually. Like I said welcome to the 21st century. 😉

[KenMcN]

BIMcloud could work for this if you could mount it on your desktop, back it up and share the files with others. But you can’t.