Just tried to create a backup file but the backup file name is truncated and the date was not appended as requested by setting.
This may be Mac specific but just tried to create a back up for a new file that I created by copying an existing file that I called JHP - 9.0.8 - 20231019.rmtree. The resulting backup file was JHP - 9.0.rmbackup. So the file name was truncated and the date was not appended.
If I modified the 9.0.8 to 9-0-8, that all worked as expected. RM seems happy with the periods/full-stops in the data file name, but not in the backup file name.
May have been reported before but a search of the forum didn’t bring up anything. As I said, may be Mac specific. Happened on 9.0.8, but hadn’t tried this format of file name recently (if ever) so probably not specific to the new level.
It’s due to the filename have dots in it. It sees the dot as where the extension is and will end there. Filenames should not have extra periods in them. It will happen in any version.
According to Microsoft, the only restriction in using a “dot” in a filename is that it cannot be the first or last character. It is not listed in the list of filename reserved characters foundHere.
But RM may operate differently than MS or mac standards.
So, we seem to have concluded that using a period/dot/point/full stop in a file name is valid in both Mac and PC, so this is a bug in RM, an easily bypassed one, but a bug no less.
mac file names are very flexible and long but only one period is allowed followed by the file extension. jones 23 10 18.jpg but not jones 23.10.18.jpg.
I don’t think this is true ----
It seems quite happy with the 2 periods in the 9.0.8 in the above, so file extension in this case. It was just the RM backup stage that didn’t handle it.
Whether “bug” or “unsupported feature” is moot but it has the same result. With a legacy originating in DOS, it’s also unsurprising. RM’s backup function likely uses a third-party Zip library so it’s possible the RM developers would need it to be revised and that’s outside their control.
Then that is a shortcoming that Apple must have introduced after Mac OSX.
Actually it is very surprising. That means that the ZIP lib that RM is using would have to be at least 20 years old and probably older than that. I would say that it is way past time to upgrade that particular development tool.
I reported this bug in V8 beta.
It is a bug.!!
How many people have to discover this and try to troubleshoot.
If you insist on DOS naming conventions, please document it.
Not a practical problem just something to avoid with spaces, commas, /s, or dashes. One of few name limitations.
/'s are a no-no in Windows also. However, just for amusement, I did a little Googling. Apparently multiple . are not a problem in Mac operating systems and haven’t been for many years. I thought it rather strange that one could do that in Windows when such an obviously superior machine didn’t allow it.
This older thread ALSO related to such a shortcoming of the file-picker functionality (quotes surrounding a filepath/filename):
Media Filename Pasting produces an eight times repeated version - RootsMagic - RootsMagic Community
Wrong! The file name extension is what ever follows the last dot.
It’s a simple pattern match to extract everything up to the last dot to use as the base name when forming a backup file name.
You misread this accurate description of how RootsMagic processes filenames as the definition of how it should work. In that respect and as advice on working around its deficiency, it is correct.
However, a complete response from @rzamor1 would recognise that multi-period support for the names of files and paths is an enhancement request and that it has been passed on to the developers.
I was describing how Microsoft and almost every other software package treats file names with multiple dots. RootsMagic is the only software that I’ve come across in recent years that fails to interpret them correctly.