Knowledgebase: GroupDrive
|
Microsoft Word Document Sharing Conflicts
Posted by SRT HelpDesk Admin on 16 March 2005 10:18 PM
|
|
|
UserA and UserB are trying to use the GD client to work on a Microsoft Word document, but are having problems. Here�s the scenario and results: 1. UserA uploads a Microsoft Word document. 2. Shares it with UserB and enables all permissions. 3. UserB links to file (Clicks �add� and �ok� the apply button is grayed out). Refreshes client interface. 4. UserB opens the file and adds one line. 5. Now UserB does a save from the file menu and closes the file. Results: UserA does not see any changes and now UserB has 2 copies of the file showing in GroupDrive. They have different timestamps but neither shows the changes. Solution: Sharing Microsoft Word documents is not a good idea when using the desktop client interface. It's much better to share the folder with somebody. The problem is when Microsoft Word saves the document; it saves it to a temp file and then renames that file into the original file. When this happens several problems could occur, first off if you don't have write access to that folder then the save is going to fail, and then there are issues with renaming and deleting shared objects. GroupDrive has a special workaround registry setting to make word work in these situations where the permissions need to go along with the original file. However this workaround is only needed under Win2k, under XP it should already work fine the way it is; however there is still the directory permissions issue. There are other applications besides Microsoft Word where it simply doesn't work to share it at the file level, emacs for instance will not transfer file permissions when saving a file, it doesn't work under Native NTFS either. Many other applications behave similarly. So the easiest way to bypass the entire issue is to give the user WRITE permissions to the entire folder, not just the Microsoft Word document in the folder. | |
|
|
|
Comments (0)
