Multi User

[Andy121070]

We are running the 6.5.5 Build 3020 Professional Edition of Help and Manual. We have put the uncompressed project onto a network drive whereby two machines can access the project. When user A edits a topic (and not yet saved the changes), user B does not get notified that the topic is locked by user A.

Is there something we are doing wrong to cause this effect? To simplify the scenario, there is no version control software in place on the project folders. (We have tried it with the SVN repository on the project folder and get the same result)

[Tim Green]

Hi Andy,

We are running the 6.5.5 Build 3020 Professional Edition of Help and Manual.

You're using an outdated version. The current version of HM6 is 6.5.6 Build 3027. You can download the installer here (just install on top of your current version to update):

http://www.helpandmanual.com/downloads.html#oldver

(We have tried it with the SVN repository on the project folder and get the same result)

SVN never locks topics, it works completely differently. Users never work on the same copy of the project at the same time with SVN. Instead, they work on a local copy on their own computer that they synchronize with SVN before starting work (to get the current changes) and after finishing work (to add their changes to the master copy).

We have put the uncompressed project onto a network drive whereby two machines can access the project. When user A edits a topic (and not yet saved the changes), user B does not get notified that the topic is locked by user A.

Then Windows file locking is not working correctly in your environment. You shouldn't try to do multi-user editing in this setup until you have located and corrected the problem. Is it possible that you are running Help & Manual in a virtualized environment, for example in Parallels or VMWare Fusion on Macs? These systems sometimes fail to provide proper Windows file locking outside of the virtual machine, i.e. when you are accessing a drive that is not in the virtual machine.

[Andy121070]

Thank you for the quick response.

The SVN involvement in this is not so much the issue as that was just to complete the picture regarding the environment that we are running.

We have now copied the project to another drive and that works as expected so this looks like a file locking issue, thank you for that Tim.

[Andy121070]

We have now done a bit of digging and testing on the server.

Using PowerShell to lock the file on the network drive:

Code: Select all

$file = [System.IO.File]::Open(“V:\MyProject\Topics\MyTopic.xml”,”Open”,”ReadWrite”,”Read”)

If we go to the topic in Help and Manual, the topic is locked as expected. If we try to modify the topic from within Help and Manual the topic is shown as read-only as we would expect.

We then unlocked the file with

Code: Select all

$file.close()

Editing the topic after this does not lock it in the filesystem.

What kind of locking is Help and Manual doing on the files? Is there a test we can run to see if the network drive is providing the sort of locking you need, or alternatively, can you tell us what kind of locking configuration you need?

[Michael Schwarzl]

Hello Andy,

we lock the files using the CreateFile function of the Windows API. ( https://msdn.microsoft.com/en-us/librar ... s.85).aspx )
The parameter DesiredAccess is set to GENERIC_READ and ShareMode to FILE_SHARE_READ. So the file is read only until the lock is released.

[Andy121070]

We have not got the project setup on a network drive with multiple users accessing it. While we are able to update the content as expected, the whole environment seems to be very laggy and slow to respond to instructions to the point where you can see it drawing the table of contents on the left.

Is there anything we can do to resolve this short of it being a networking issue? We do not appear to have any problems with other applications across the same network drive.

[Tim Green]

Hi Andy,

We have not got the project setup on a network drive with multiple users accessing it. While we are able to update the content as expected, the whole environment seems to be very laggy and slow to respond to instructions to the point where you can see it drawing the table of contents on the left.

Is it possible that you have the project managed in Subversion or Team Foundation Server and your working copy on a network drive? If that is the case that would explain the slow performance. Putting a version control working copy on a network drive will cause MASSIVE loopback problems with the server and will very seriously impair performance. Version control working copies should always be for one person only and should always be stored and edited only on a local drive on the computer of the user who owns the working copy.

Networks in corporate environments also often cause problems with larger projects in Help & Manual. When you are editing a project a fair amount of communication is happening between Help & Manual and the project and if there is a lot of traffic on your network and/or there are a lot of nodes or linked routers that can be enough to cause performance bottlenecks. You can test this by trying to edit a copy of the project on a local drive.