Move/Copy Companion File Issues

[dev3d]

Issue #1:
Move/Copy To fails to move companion files when performed from an image preview tab (eg. a tab opened by double clicking an image in the Browser), though it works fine when performed from directly from Browser as well as Second Monitor Fullscreen Preview:


Issue #2 (Related to #1):
Move/Copy To for Video.mp4 fails to move the Video.mp4.jpg companion file, even though Move/Copy Video.mp4.jpg correctly moves Video.mp4, when defining bi-directional multi-dot companion extension relationships by adding "Companion_00=jpg:" (which works) and "Companion_01=:jpg" (which fails to work) to XnView.ini.

Issue #2 Details:

Use Case:
I use XnView to manage a library of media, using "Move/Copy To" to move the video preview thumbnails (such as generated using Auto Movie Thumbnailer (AMT)) or cover image, such as Movie 1.mp4.jpg and have the corresponding video file automatically moved together with the preview (by having "Companion_00=jpg:" and "Companion_01=:jpg" in XnView.ini).

By adding "Companion_00=:.jpg" to XnView.ini (along with "CopyCompanionFile=1") whenever I select an Video.mp4.jpg or Video.wmv.jpg, etc. in the XnView classic browser or 2nd screen preview window, I then right click > Move To, XnView works as expected, moving the associated video file (such as Video.mp4 or Video.wmv) together with the preview .jpg to the destination selected.

Issue:
However, it is currently impossible to define a similar general rule for the reverse relationship (where selecting and moving Video.mp4 will also move the associated Video.mp4.jpg file). I tried adding "Companion_01=:jpg", but that fails to do anything, even though the reverse of "Companion_00=jpg:" works as expected. As a workaround, I have to add a companion extension definition for every possible video extension, of which there are dozens. I have included an example workaround below which has the few most common video extensions, though, besides being tedious to setup, if I want to support preview files with extensions other than .jpg, let alone supporting cases like .cover.jpg, etc., then this workaround is no longer feasible.

Workaround in XnView.ini:
Companion_00=jpg:
Companion_01=mp4:mp4.jpg
Companion_02=mkv:mkv.jpg
Companion_03=wmv:wmv.jpg
Companion_04=mov:mov.jpg
Companion_05=flv:flv.jpg
Companion_06=mpg:mpg.jpg
Companion_07=mpeg:mpeg.jpg
Companion_08=avi:avi.jpg
Companion_09=mpeg:mpeg.png
Companion_10=avi:avi.png
Companion_11=mp4:mp4.png
Companion_12=mkv:mkv.png
Companion_13=wmv:wmv.png
Companion_14=mov:mov.png
Companion_15=flv:flv.png
Companion_16=mpg:mpg.png

Suggested Fix:
I would suggest correcting this by allowing "Companion_00=:jpg" to mean "for any file, consider FileName.Ext.jpg to be the companion file." like would be expected considering the behavior of "Companion_00=jpg:".

Requested Feature and Workaround:
Also, I would suggest adding an option such as CopyFileWithCompanion=1 which will optionally allow the primary file to be moved together with the companion. This especially makes sense for video preview images, but I would think it would be desired in other cases as well, so that if you moved a .xmp file you would want to move the file the .xmp file describes as well, just like if you moved the image you would expect the .xmp metadata to be moved with it. Therefore, I would suggest this being the default, but, if not, then I would at least suggest this option be supported. If this was supported, then it might avoid the need for fixing (ensuring consistency in) the behavior of "Companion_00=:jpg".

Requested Feature for XnView MP:
Also, if/when Move/Copy Companion support is adding for XnView MP, as I (and others) have requested in the List of missing features (compared to XnView Classic) and other threads, I would ask that this use case be taken into account, and it be implemented in a way that avoids the issues described here.

Thanks very much.


Tested with XnView (classic) v2.33 (as well as most previous versions).

[dev3d]

Is this something that could be fixed/improved in an upcoming release?