Why does ArchiCAD remember user names in PLN files?

[Anonymous]

We are trying to move our Mac workstations to using AFP servers and ArchiCAD is basically making this as difficult as possible. Users constantly keep getting authentication dialogs triggered by ArchiCAD trying to open references over SMB that it already has mounted over AFP.

Looking at the PLN files with a hex editor, one can clearly see them littered with smb://username@server/share/path references. Any attempt to relink libraries or external references simply by absolute path (even by first removing them) fails and the only way to get references to work is to mount the same server again over SMB (even though the new mount is not the right path since it becomes /Volumes/SHARE-1).

Is this normal? Is there any way to keep AC (17.6004) from doing this? Is there perhaps a way to reliably rebuild external references in PLN files to point to the right server?

[Anonymous]

Edward Snowden knows why .

[Anonymous]

Yes, we experience this.

My diagnosis is that if a user links an external file in AC that info, included username and path, is stored in AC. The path includes the protocol (AFP or SMB) and so if the network share is not mounted using the stored protocol, AC will prompt the user to mount the network share (using the stored protocol).

So, if the network share was previously mounted using AFP, but is now mounted with SMB, AC won't recognize that it is mounted and will ask you to mount it again.

Bizarre behavior although I can understand why its happening. I just wish there was a transparent way for this to happen.

[Anonymous]

We had one project file where the user was completely unable to relink external libraries to use the new file server. ArchiCAD would stubbornly try to reference them from the old server. After several attempts I tried emptying the AC cache folder (~/Library/Caches/Graphisoft/*) and then re-adding the libraries actually worked.

Just a moment ago I was troubleshooting a DWG XRef issue where the user was unable to update the ref in their PLN unless they authenticated to the old SMB server (the authentication dialog was again pre-populated with another user's username). Any valid username/password is accepted and a new file server connection is created (with the -1 prefix). The Xrefs are still pointing to the right server in this case because the absolute path still points to the correct server (which was mounted first). Super dumb.

This seems like a huge design flaw to me - how can you actually use AC in a multi-user environment if any external reference can only be edited by the user who actually created the reference. Should all users use the same user account to connect to the server? I know it doesn't actually work that way (and that AC is in fact used in workgroups) but all this behaviour suggests that there's a bug somewhere in here that should be addressed and that things still "kinda sorta work" is all by accident. And the fact that the protocol prefix is stored in the PLN seems totally unnecessary to me, especially since references are always presented as absolute paths (which is what they always should be).

Years ago there was mention of the DisableCrossPlatformMountingFeatures hidden preference. I actually tried setting that, but AC 17 seems to reset it every time it's relaunched.

[Anonymous]

Relinking any/all external references using the desired protocol seems to fix it.

However, this problem seems to be more pronounced since Mavericks because the default way to mount network shares is now SMB. We still explicitly mount using AFP but sometimes the share disappears from the sidebar in finder and a user might mount by direct navigation to the network share. Doing this will mount using SMB, so AC will prompt again to login/mount the share when needed.

I don't think it is really a user/username problem it is the network mount protocol that's the problem. Switching everything to SMB is probably preferred and would eliminate some of this behavior in AC but we had other issues with SMB in Mavericks and haven't adopted it.

If you're using profile manager you can set the network mounts to load as AFP or SMB at login and this seems to help. However, they seem to unmount periodically which forces the user to manually mount again (usually by navigating in the Finder) which might cause the share to remount using SMB and the problem can begin again.

Difficult to describe, but its a regular occurrence. I blame the problem on Mac OS but GS should find an elegant way to address it.

[Da3dalus]

We had this problem back in 2013, but solved it by completely eradicating the SMB network, and painstakingly relinking Hotlinks, Drawing Links, and Publisher Sets to the AFP path in HUNDREDS of active projects. Our office is all-Mac. Not fun.

Things have been much better, but since then, SMB has become the preferred protocol of Apple (I'm not sure how much longer AFP will live), and the growth and management of our company is requiring Windows integration (yes, Revit), so we're planning to convert back to SMB.

Can anyone tell me if this issue has been resolved, as of ArchiCAD 20? Have the logins been removed from the paths in Mac? If I change my protocol, will all of my thousands of links be broken? If so, it's going to be a lot of lost hours!

[Anonymous]

Nope. As far as I am aware the behavior in AC remains the same. I've got to switch to SMB only as well, but dread it because of this issue.

It has only been made worse since Apple started defaulting to SMB when a user browses to the server in Finder. Finder still after all these years won't retain network share aliases in the sidebar. So when a user loses network connection the alias will disappear. Then they will always browse to the share and for that session the share will be SMB not AFP.

For a couple of years I've just kept both SMB and AFP running knowing/hoping that the act of users browsing via SMB might eventually overtake AFP use on new AC projects.

I guess the only way to know how successful that has been is to turn of AFP and listen for the screams. 😉

[Erwin Edel]

SMB on our macs is dodgy at best. Connection to the server comes and goes, saving back files that you opened an hour before, sometimes yields error messages about read/write rights and such. I'm no MAC guru (far from it), but a few quick google searches showed that this is a common problem with MAC and some suggested getting 3rd party software as the apple software isn't working properly. We do not use the macbooks enough for ArchiCAD at the moment to merit that investment.

That said, if this about network paths, we have no problems there. We use both windows and OSx in the office and our server runs on windows server. Projects open fine on either platform and the libraries, modules, etc are found when using network links. 'Mounting' the network to a path like U:\ on windows and linking to that does not work between the two platforms, but just straight linking the network adress works fine.

[Anonymous]

I've been testing file operations over SMB from our Macs. Speed is slow at best. Usually about half as fast as AFP. What garbage!

I've tried adjusting server-side and client-side settings advertised online to improve speed from Mac clients, but nothing really helps.

I've even tried various SMB servers, including my Mac server, Freenas, various other linux distros and it's consistently slow. Apparently Apple has deprecated AFP in lieu of SMB without actually making it work.

[Anonymous]

Just for grins, here are the results of SMB vs AFP test. I'd like to see if others could post their results here, too.

1. Open a Terminal Window and type rsync --stats --progress
2. Next, drag a large file (larger is better) from Finder to the Terminal window. This will drop the path of your source file into the command.
3. Finally, drag-and-drop a folder on your server to the Terminal window to drop the destination path of your SMB server
4. Press Return to execute. Note the results.
5. Repeat steps 1-4 except change the destination path to a folder on your AFP server.

In my results below you can see that the file copied over SMB at 28.25 MB/s while the same file copied over AFP at 50.19 MB/s - nearly twice as fast.

eric:~ ebatte$ rsync --stats --progress /Users/ebatte/Desktop/16-895.235.T\ -\ Lively\ Exploration\ 16-895.235.pla /Volumes/Shared\ Folders/Projects 
16-895.235.T - Lively Exploration 16-895.235.pla
    83875888 100%   28.25MB/s    0:00:02 (xfer#1, to-check=0/1)

Number of files: 1
Number of files transferred: 1
Total file size: 83875888 bytes
Total transferred file size: 83875888 bytes
Literal data: 83875888 bytes
Matched data: 0 bytes
File list size: 67
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 83886253
Total bytes received: 42

sent 83886253 bytes  received 42 bytes  23967512.86 bytes/sec
total size is 83875888  speedup is 1.00
eric:~ ebatte$ rsync --stats --progress /Users/ebatte/Desktop/16-895.235.T\ -\ Lively\ Exploration\ 16-895.235.pla /Volumes/Shared\ Folders-1/Projects 
16-895.235.T - Lively Exploration 16-895.235.pla
    83875888 100%   50.19MB/s    0:00:01 (xfer#1, to-check=0/1)

Number of files: 1
Number of files transferred: 1
Total file size: 83875888 bytes
Total transferred file size: 83875888 bytes
Literal data: 83875888 bytes
Matched data: 0 bytes
File list size: 67
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 83886253
Total bytes received: 42

sent 83886253 bytes  received 42 bytes  33554518.00 bytes/sec
total size is 83875888  speedup is 1.00
eric:~ ebatte$ 

FYI, server in my test is a MacOS Sierra Server running both SMB and AFP.