Copy *.propcols to the other Apps

[Widestone]

I have tested (in the newest Beta Versions) to copy the *.propcols of BRUSHES, VECTORBRUSHES, FILLS and STYLES. No problems so far. And much less work

Is this an (official or korrekt) way to do this or can it make problems? Is the format equal in all 3 applications? If YES, it would be nice to have the settings for this in only one directory (userdefined if YES or NO) to "synchronize" the Apps automatically. 

Only the ASSETS make problems. But maybe is one of them corrupt.

[stokerg]

Hi Widestone,

You are using the method we would recommend for synchronizing between computers.  This shouldn't cause any problems.

As for the Assets file, do you get an error or do they just not import?

As for a shared folder for all of the settings, i know it's been mentioned before, so may happen at a later date  

 

[Widestone]

After copying the Assets.propcol and restart the other App the App crashes after restart (while or after loading the fonts). If I delete the assets.propcol and restart all is ok.

 

[Widestone]

I forgot. I used the assets.propcol from Photo or Designer. And the Publisher crashed.

[walt.farrell]

13 minutes ago, Widestone said:

I forgot. I used the assets.propcol from Photo or Designer. And the Publisher crashed.

Same release level of Photo/Designer and Publisher? You wouldn't be able to copy a 1.8 .propcol file to a 1.7 application successfully.

 

[Widestone]

Yes - all latest Betas.

Will test with the "fresh" Beta of today.

 

[Widestone]

beta-1.8.0.549 is not crashing with a copied assets.propcol and works

 

While starting Publisher makes some *.propcol - Backups and decreases the 2 brushes.propcols. Are some brushes incompatible and will deleted or why does Publisher this (also in the former beta)?

[walt.farrell]

2 hours ago, Widestone said:

While starting Publisher makes some *.propcol - Backups and decreases the 2 brushes.propcols. Are some brushes incompatible and will deleted or why does Publisher this (also in the former beta)?

If I remember correctly there was a problem with the *.propcol files never decreasing in size, even if the user had deleted some brushes. Possibly you're just seeing the effect of cleaning up the files to eliminate wasted space for previously deleted brushes.

[evanmac]

On 2/5/2020 at 12:36 PM, stokerg said:

You are using the method we would recommend for synchronizing between computers.

 

Hi, I'd like to sync beetwen two computer, but I can't find what is this "procedure".
Can someone point me to right direction, please?

[walt.farrell]

2 hours ago, evanmac said:

Hi, I'd like to sync beetwen two computer, but I can't find what is this "procedure".
Can someone point me to right direction, please?

It involves copying the internal files maintained by the application. The location, names, and contents of the files are described in this FAQ:

Of course, the application should not be running when you copy the files.

I believe it was only ever officially suggested for copying between the beta version of an application and the retail version, and then only for users who purchased directly from Serif. As I recall it was not recommended for users who purchased from the Mac App Store or the Microsoft Store. 

I have had good results doing it, but I don't know that it is an action that is officially supported, and I would make a backup of the existing files on the target computer or application before replacing them.

[evanmac]

6 hours ago, walt.farrell said:

It involves copying the internal files maintained by the application. The location, names, and contents of the files are described in this FAQ:

So, if I understand correctly, moving (and symlinking) those folders to a net-shared one (icloud or dropbox, for instance) would make the trick?

[NotMyFault]

53 minutes ago, evanmac said:

So, if I understand correctly, moving (and symlinking) those folders to a net-shared one (icloud or dropbox, for instance) would make the trick?

It really depends on your risk appetite and backup method.

Affinity apps like to occasionally produce corrupt files, especially when accessing NAS or cloud storage, or USB drives.

Just give it a try, but make backups or exports of those file’s whenever you add valuable data into them. 
If it works, you are lucky. If you run into issues, use the backup for recovery and revert to other methods.

Nobody knows if Affinity locks file against parallel write operations, and re-loads files after startup when the other side changes them. I would assume if you add to assets on all synchronized Apps, the later write can overwrite the earlier write. Curious to hear if it goes well.

But even if it works with current release, there is no guarantee it works after any upgrade.

[walt.farrell]

1 hour ago, evanmac said:

So, if I understand correctly, moving (and symlinking) those folders to a net-shared one (icloud or dropbox, for instance) would make the trick?

What are you trying to accomplish?

The applications are not designed to allow the files to be shared, so you would need to make sure that only one computer was accessing the file at a time, and only one application on that computer was using the file.

[evanmac]

17 hours ago, NotMyFault said:

It really depends on your risk appetite and backup method.

Affinity apps like to occasionally produce corrupt files, especially when accessing NAS or cloud storage, or USB drives.

I have all of my work saved on iCloud Drive, and never had a fault. I know that we are talking about configs file, but I don't think I'll have any problem

[evanmac]

17 hours ago, walt.farrell said:

What are you trying to accomplish?

The applications are not designed to allow the files to be shared, so you would need to make sure that only one computer was accessing the file at a time, and only one application on that computer was using the file.

I work on two different workstation (in two different locations): one to create and manipulate, and the other to send the files to printer

What I'd like to accomplish, is, for instance, to sync the styles (text, shape, chars, etc.) between the two machines, or the brushes, etc.

I know I can donwload the resources from my affinity account on both devices, but it isn't enough for my workflow

I'm sure that the apps themselves are closed (not only the files(s) I'm working on) once I open on the other workstation

[NotMyFault]

18 hours ago, walt.farrell said:

What are you trying to accomplish?

The applications are not designed to allow the files to be shared, so you would need to make sure that only one computer was accessing the file at a time, and only one application on that computer was using the file.

Lucky boy 👍🏼
Crossing fingers that it works well. Please share your experience after using this for some time, including at least one release upgrade.

[Widestone]

The *.propcols can be very large (some GBs). That can be a problem when storing on LAN or NAS or Clouds. And the accessing from more than one computer simultaniously too. To use the same *.propcols for AP and AD and AP is not a good idea. Some things stored in this files can't be used in all programs and make crashes on starting the applications.

My setup with no problems on MultiBootSystem since years is:

2 Hardlinks or Symlinks from the Locations "C:\Users\xxx\AppData\Roaming\Affinity" and "C:\ProgramData\Affinity" to a different local drive (before installing the Apps)

[v_kyr]

21 hours ago, evanmac said:

So, if I understand correctly, moving (and symlinking) those folders to a net-shared one (icloud or dropbox, for instance) would make the trick?

Make the net-shared here intranet-shared, as far as the intranet is very fast & always stable here. - Further a syncing via getting then always an up-to-date local copy of a main intranet backup storage place might be even more secure here in terms of Affinity apps usage.

One can also setup some personal central GIT repository for sharing those things, which is then always kept up-to-date and will be from time to time updated in case of some machine's Affinity *.propcols additions (GIT push). The other machine then does a GIT sync and should then be always provided with the latest additions from the central repository. -  Of course there is also other software which allows to sync from a central intranet place and thus to always provide a local copy then on a change of the central one!

The above wouldn't need any symlinks at all, since it's overall more like a copy/update operation. Though on a fast & stable local net, sharing via just symlinking certain files might be also an acceptable option.