Dropbox and Vectorworks Project Sharing Issue

To be clear....the biggest issue is that once the Project File (.vwxp) file is deleted and then replaced during a Save and Commit process it is no longer set to MAKE AVAILABLE OFFLINE meaning it no longer exists in your local dropbox folder but resides only in the cloud.  When this happens your Working File (.vwxw) located on your local drive can no longer 'see' the Project File.  You have to tell the Project File you want it available offline again (on your local drive) for the two files to see each other.  Issues arise when this happens in the background on your station as a result of your team members Save and Commit.

 

Using 'Safe Save' mode as suggested above seems to have resolved this problem.  This setting does default to being 'off' so you must remember to set this every time you create a Project File.

On 7/31/2024 at 6:54 PM, Joe-SA said:

To be clear....the biggest issue is that once the Project File (.vwxp) file is deleted and then replaced during a Save and Commit process it is no longer set to MAKE AVAILABLE OFFLINE meaning it no longer exists in your local dropbox folder but resides only in the cloud.  When this happens your Working File (.vwxw) located on your local drive can no longer 'see' the Project File.  You have to tell the Project File you want it available offline again (on your local drive) for the two files to see each other.  Issues arise when this happens in the background on your station as a result of your team members Save and Commit.

 

Using 'Safe Save' mode as suggested above seems to have resolved this problem.  This setting does default to being 'off' so you must remember to set this every time you create a Project File.

There's an easy fix for this. Simply set the folder in which the project file resides to "Available offline". Then all files within this folder will always automatically inherit this property and always be available.

 

@Antonio Landsberger Correct!

 

Recently we have worked with our project sharing gurus to update our 'Project Sharing Getting Started Guide' (see attached).

 

This file can also be found as part of this Vectorworks University 'Coffee Break - Project Sharing in Vectorworks'. The Coffee Break session needs updating, but the 'getting started guide' is up to date.

 

Please let us know if you have further suggestions for the guide.

Project Sharing Getting Started Guide v1.2.pdf

I posted the following in a different 'Troubleshooting' thread but thought it would be better here.

We've recently been using VW2025 Project Sharing and I'm telling you the current state of things is not good.  Project Sharing should not be considered 'fixed' by any stretch and it appears that poor work arounds have been adopted as the prescribed methods because the true fix wasn't achievable.

 

Here is what I posted after finding out that the .vwxw backup files are now purposefully .vwx files instead of .vwxw files.

 

When you have a sudden crash you have a number of things checked out with exclusive access.  Those items are still checked out in your vwxw Working File but that file doesn't contain your latest information that is only in your last autosaved Backup File.  When you open you Backup File (now a vwx) how are you suppose to get that information that only exists in that file back into your vwxp Project File?  Does it still have some magical link the vwxp file?   How do you Release what was checked out when it crashed? If you open your Working File it will sync outdated information.

 

In the past we would open the Backup vwxw file, immediately Save and Commit and Release all checked out objects.  Then close and re-open a fresh vwxw file.

 

My co-worker just crashed and asked how he was suppose to get the latest items since his last commit back into the vwxp file.  I didn't have an answer.  What is the new prescribed method in VW2025?  He ended up sifting through what he could remember and cutting and pasting.  This can't be what is the intended workflow.  

 

I've read in another thread how this change 'fixed' the issue of a Backup file not having the same information as what had been committed to the Project file.  Seems like the solution could have been just updating the backup file automatically with every Commit.    This 'fix' being offered is solving a problem we never ran into while we now have new problems that open the door to actually losing time and work effort...something the backup file is suppose to mitigate.  

 

Additionally, with the removal of 'Safe Save' to cloud drives (dropbox) we regularly get conflicts with Saved Views, Viewports, and Styles where we have to choose whose version we are suppose to keep and whose will get overwritten.  This often is happening when nobody has a recollection of making a modification to that item.  If it resulted from some simple Class editing than every viewport or saved view with that Class would have been tagged but it seems to only be one or two instead of all of them.  We don't see any rhyme or reason to what is conflicted and what isn't.  We do know, that when we specifically edit Saved Views and Viewports we risk those edits getting lost in this new conflict unique to VW2025.  I suspect it has to do with the Folder being the sync item instead of the VW File itself.  Communication with the VWXP file is constantly being broken and re-established after a delay of many minutes which opens up the door for these conflicts.

 

My hope with the all new back end coding changes to Project Sharing was that it would run smoothly and my skeptical co-workers would start relying on it.  Our experience in VW2025 is actually worse than we had with VW2024 with Safe Save mode running.

@Joe-SA

Dropbox and the backups are two different topics.

 

On the topic of backups:

Using working file backups often times cause issues, which is why .vwxw backups were changed to be .vwx backups.

 

For the time being I suggest changing the autosave settings from "Autosave a backup copy to" to "Overwrite  original file" with a short save interval to have your working file have the most recent state possible.

 

I understand that this is not ideal, but we have brought forward a feature request, to enable having both options:
1) autosave (overwrite) the current document in a certain interval

and

2) autosave (a backup) in a certain interval

 

The issue is not with the backup saving .vwx files. The crashes are. Please report these to your local distributor.

We have switched over to 'overwrite' which is an improvement over saving a separate .vwx file as a backup.   

 

With regard to the conflicts we are seeing with Saved View Settings, Viewport Settings, and Viewport Style Settings seemingly not 'sticking' to the .VWXP file or being asked to chose one Working File's version over another...I'm curious if one semi-hidden section of the Save and Commit dialog box has any impact.

 

In the Commit box there is a 'More>>' button which opens to two toggles that are turned off by default.  One allows you to sync the Document Preferences and Settings from Working to Project while the other would push the Navigation and View Related Settings to the VWXP.  In reading through both of the specific lists of criteria these toggles control a lot of things related to the Organization Dialog box and Active settings for the document which might be considered user preference or specific to one person's workflow but I'm not seeing anything specific to Saved View and Viewport Settings.  Could it be that one of these toggles is what I'm looking for to get my Saved View Class and Layer changes to sync back to the Project File permanently?  We need to do more testing but our current suspicion is that this is the fix.  If that is the case maybe what 'is' and what 'is not' controlled by these toggles should be evaluated.

 

Edited June 3 by Joe-SA

@Joe-SA For project sharing workflows, when using a cloud service, it is critical to save the parent folder housing the project file in offline mode, not just the project file itself.

 

If you have a lot of files in that folder, to reduce internet / network bandwidth, then I would create a project specific folder that only contains your .XWXP files (and the resultant project file backups).

 

I hope that helps.