Shared network directories - unsuitable for group work
Files shared by a technical writing team are often stored in a shared directory on the network.
Technical writers work directly on shared files, which poses the following challenges:
- Risk of data loss in the event of network failure.
- Limited possibilities for offline work.
- Locking of files by team members who have opened them.
Even with frequent backups, directories are not a secure repository for data. The granularity of the backup is at the directory level, and backups are often only daily. In the event of data loss, restoration is done directory by directory, not file by file, and involves versions whose age depends on the system administrator, not the technical writer. Searching through archives is a tedious operation that can lead to errors; without a reliable and easy comparison between several versions of files, the technical writer can easily lose changes they intended to keep while trying to restore others.
Copying a file from the network to modify it on a personal hard drive and then overwriting the network version with the local version is a risky operation:
- Team members are not notified if another member is modifying the same file simultaneously, leading to potential loss of changes by one of the technical writers.
- When manually copying files, either via a graphical file manager or from the command line, the technical writer can easily overwrite the most recent version with an older one. A file synchronization program such as rsync or Unison (the latter being better suited for bidirectional synchronization) from the command line under GNU/Linux or Windows, or a graphical equivalent such as SyncToy, is recommended. However, these programs rely on the last modification date of the files. When updating or publishing a FrameMaker book, for instance, this can create conflicts between files, as FrameMaker saves all the files in the book, even if their content has not been modified.