I have Geneated a book file as normal,
When i go to save it using this name "CW1040-9 ILLUSTRATED PARTS LIST REV 17 - V20A012.book" Framemaker has started to shorten it to CW1040-9.boo
After checking with other files it seems to do the same with standard .fm files (limits to 8 chars + 3)
This has only started happening today, I have no idea why, i tried restarting the machine but it still the same.
I have tried it in other programs and they are fine (just framemaker).
Any help will be appreciated.
What's your FrameMaker version? Do you have all FrameMaker updates?
Does this happen also with new files? Or only with existing files?
You do not use any structured application, don't you?
Do you have a connection to a CMS?
Are there any updates on your PC?
What's your FrameMaker version? Current Version 16.0.3
Do you have all FrameMaker updates? Yes
Does this happen also with new files? Or only with existing files? New and old files are changed
You do not use any structured application, don't you? Unstructured only
Do you have a connection to a CMS? No
Are there any updates on your PC? All up to date as far as i can see.
What is confusing is that it worked fine yesterday and 2-3 hours ago, it has started happening in the last 90 minutes.
Are your files in a special folder?
Or on a special server?
Could it be that the folder got new rules?
When you create a new file and save it, where do you save it? Does this happen everywhere?
Could you switch to the structured interface (with FrameMaker restart) and then try again and then back to the unstructured interface? It could be that this resets something.
Sorry. Very strange. I do not know, what could cause this.
I can beleive i didnt check the folder location first... Its a server issue.
Thank you for sending me looking in the right direction.
re: CW1040-9 ILLUSTRATED PARTS LIST REV 17 - V20A012.book … CW1040-9.boo
In addition to the now-identified server issue, which appears to be crushing filenames to the legacy DOS 8.3 or ISO9660 syntax, the original file name has spaces in them.
Although the planet is trying to get smarter about that, spaces in file names remain unwise, particularly where the file name will be handed off to any sort of script or batch processing, perhaps without notice to you. This may very well either parse on the spaces (truncating the name and then failing), or attempt to escape it (%20 and suchlike), and perhaps not later converting it back. When I need to preserve character gaps, I use "_".
Older versions of Windows FM, itself, did have a problem with imported objects that had commas in their filenames. I haven't tested it lately.
I ran a test yesterday on FM2020, and saw no issues with commas. If you can generate a simple repeatable case, by all means report in on Tracker.
For my test, I used a .fm file name with a comma, in a dir with a comma, importing an inset file with a comma in its name, from a subdir with a comma. Published with no issues.
Good if they fixed in FM2020 🙂 . Too bad for those of us that aren't on FM2020 - benefit of upgrading, perhaps?
FM2019 is theoretically still in support, so if you can create a simple test case that reliably demonstrates the problem, and report it on Tracker, it might get fixed. Whether anyone's IT department would then apply any resulting update, I can't predict.
An interesting aspect to this problem is that it might be there on some builds & platforms, and not on others. It may well be lurking in FM2020, or even re-emerge in some future release. It might also be an OS problem in the filesystem stack.
Back when I was in a production environment, on FM7.1/Unix, the problem didn't happen. On FM7.0/WinXP, it did; same FM codebase, both 32-bit. I just got out of the habit of using commas in dir&file names.
I'm also in the habit of avoiding commas in directory and file names. (Which is probably why I was caught out that one time.) I've seen it case issues with scripts, so I've made it a policy that folders and file names used with FM cannot contain commas.