Relative file pathnames in FM book files

[Becky_Swanson]

I haven't had the opportunity to use FM in several years, but recently installed FM 11 on a Windows 7 laptop. I work on a network, and generally save my files there, but have had some network issues, so I copied my project folder to my desktop. The folder contains the FM Book file, along with all the chapter and generated files. However, when I open the Book file which was copied to my local drive, all the pathnames for the chapters and generated files are shown as absolute paths to the files on the network drive. How can I fix this? I need to use the files that are on my local drive.

The last version of FM that I used regularly was FM7.2, and I believe it saved all book file entries as relative pathnames, did it not? Is there a setting to enable relative pathnames for files in a book?

Thanks!

[Bob_Niland]

Work-around until the answer is found:

Don't copy the files to your local drive.

Open them on the network in FM.

Re-save to local drive.

[Van Kurtz]

I disagree with Error, but it depends.

IF the files on the network are ALL on the same server, then all the pathnames should be relative. If you then copy (using Windows Explorer) ALL the files to the local drive AND maintain all the relative locations (that is, folders and subfolders), then the relative pathnames remain. Explorer does not change anything. Make sure you copy all the linked files, such as graphics files, too. So, the files should open on the local drive without problems.

Note that if you opened the book on the network and then saved it to the local drive from within FrameMaker, then FrameMaker changes the paths to absolute because it thinks the files within the book are still on the network.

[Bob_Niland]

> I disagree with Error, but it depends.

Oh, indeed. We haven't even talked about imported objects.

In the Unix world, where Frame began, this abs.vs.rel path issue doesn't often arise, because everything is referenced to "/". Mac I can't speak to.

You can copy stuff in Unix as long as the new location is the same relative tree depth as the old. We do this often. No problem. If you need to adjust the tree depth, you have to re-save, and we do that.

In the Windows world, everything can be relative, but only if it's all on the same logical drive (letter). If all the paths of the document files and imports start with, say "C:\", relative is possible. But if some of it is on, say, network drive "N:\", you now have an intractable problem. Those paths will be absolute, and worse, will be that specific alphabetic drive letter (thanks Mr. Bill). Copying files, then opening, will fail. Opening and re-saving won't. Even on the same logical drive, however, the tree depth constraint still applies.

I've had to explore this a bit, because in my day job, all the FM7 files are on a Unix NFS, but we expect the FM clients to become PCs at almost anytime, and we needed to know how to map the NFS onto a drive letter so that everything opens in place as-is, without errors*. We are ready for that migration.

I also work at home (Windows) on some content, and have been able to mimic the NFS file tree so that I can copy content without re-saving. It can be done, but again requires attention to the file tree.

* Other than the nuisance graphics import filter errors.

[Matt S - Tech Comm Tools]

I'll let Arnis chime in here…

There's an issue with references when moving docs to/from networks.

Specifically, I'd probably just recreate the book file when the files are in their final location.

[Arnis_Gubins]

Becky,

How was the network location specified, as an UNC path or a mapped drive? With the UNC paths, IIRC, FM will always use absolute pathnames and if the mapped drive points to the top level, i.e. you map Z: to a network machine,drive and folder nesting, then that is treated as the root of the drive and all references become absolute as well.

You always need to be one level down from the drive root for FM to use relative path names.