Versioning to the target folder tree

[Shacho]

Versioning to a single folder does not work for me.
I want to move the old version of the target file into the same folder as the target, but with a different name. Since internal macros such as %target_parent_folder% do not exist, FreeFileSync does not natively support this directly.
This is not quite what I am doing but suppose you wanted to sync your documents folder on drive C: that has a tree structure the Swiss Family Robinson would be proud of, to a second drive say D: and you wanted to maintain versioning (history is a better term). Following FFS process, the versioning could be placed on a third drive E:. Some time later you find you need to find a previous version of a file. This requires navigating the tree on drive E: to find the previous versions.
What I want to achieve is:
• file.txt from deep down the tree structure on Drive D: copied to the same location deep down in the tree structure on drive D: with -YYYYMM appended to the file name ie file-YYYYMM.txt
• file.txt from deep down the tree structure on Drive C: copied to the same location deep down in the tree structure on drive D: ie file.txt as per normal.
In my situation there will rarely be more than 2 "backup versions" and I would prefer they were in the same folder.
I have consulted with ChatGPT which initially suggested there are internal macros that could assist with this but it was wrong. The macro it suggested was %target_parent% but entering this in the "Move files to a user-defined folder" setting did not work. FFS did not recognise the macro and added the local file path to the FFS program files.
I have looked into creating a user defined macro either in the globalsettings.xml file or in a FFS batch file but as there is no clear option for accessing source and target paths I am at a loss as to how to proceed.
There are very few examples of macros to see just how they need to be coded to satisfy the FFS engine.
Any help/advice would be great.
I would also like to suggest:
• a full list of internal macros and their scopes
• adding the following as suggested by ChatGPT:
ChatGPT says: Available Macros in FreeFileSync
Here are some useful built-in macros you can use:

Macro Description
%timestamp% Inserts the date/time when the file was replaced
%date% Inserts the current date
%time% Inserts the current time
%source% Inserts the full source file path
%source_name% Inserts the source file name (without the path)
%source_parent% Inserts the parent folder of the source file
%target% Inserts the full target file path
%target_name% Inserts the target file name
%target_parent% Inserts the parent folder of the target file

[Plerry]

It is of no use to discuss the need for/usefulness of additional macro's for FFS Versioning.

Versioning (in)to the same target-/right-side folder that (at least after the sync) holds the most recent version of a file, conflicts with the basic way FFS performs syncs, and would involve a complete and dramatic overhaul of FFS.
For FFS, your Versioning location must be simply outside your left and right base location, or otherwise explicitly excluded form your left and/or right location via FFS's Exclude Filter.

In my view: your proposal is extremely unlikely to be implemented in FFS.
So, don't hold your breath!

[xCSxXenon]

https://freefilesync.org/manual.php?topic=macros
We should ban ChatGPT from being mentioned in this forum. It is literally wrong every time it gets used

[Shacho]

Thank you for your prompt replies.
xCSxXenon - unhelpful, unwarranted and understood long before posting.
Plerry, Thank you. I do understand the conflict, but I have always taken the view with coding that if it can be imagined/conceived than it is possible - it is just working out the how.
Are you saying that I could put the base directory for the target location provided I exclude it using the filter? It deems to me that would result either all files copied over with a rename of existing or FFS deciding there was nothing to compare on one side.
I just had another thought: I think it should work as a two stage process? Stage 1 do the sync with versioning to an external location; Stage 2 Sync the external location with to the original target with a custom sync on the left side of Create; Update & Delete. This should achieve the desired result. I'll give it a try and post an outcome.
I haven't tried but can a batch file contain multiple sync processes as suggested here?

[Shacho]

The two stage approach works but it seems it can't be done in the one sync operation even on separate lines.
Two separate sync processes are required.
In stage 2, I opted to delete the files (these were the versioned files from stage 1 and the source files for stage 2) but they were not deleted. Could this have something to do with sync.ffs_db being present in the root folder?

Why does the "Time stamp (file)" option not do what is expected?

I would expect:
\Folder\File.doc
would result in
\Folder\File YYYY-MM-DD hhmmss.doc
but it produces:
\Folder\File.doc YYYY-MM-DD hhmmss.doc

Is this a glitch?

[Plerry]

> I would expect: ... Is this a glitch?
The behavior is exactly as described in the FFS manual page on Versioning.
If you choose the Replace or Time Stamp [File] Naming Convention, the most recent previous version is always saved as [VersioningLocation]\Folder\File.doc (as per the manual page item 1), without timestamp.
If you choose the TimeStamp [File] naming convention, any earlier previous versions are named
[VersioningLocation]\Folder\File.doc YYYY-MM-DD hhmmss.doc (as per the manual page item 2)

The fact that the most recent previous version is always saved without timestamp causes that your 2 stage approach does not work. The file File.doc in the Versioning location is the most recent previous version.
However, depending on your sync settings, in your 2nd stage sync that most recent previous version will replace the actual/most recent (non-previous) version of File.doc, or you will simply loose the most recent previous version of File.doc.