#1495 Possible Wildcard Matching Bug with Data Privacy Implication

[Carl Coffey]

Hello Igor/team,

I am specifying a command line as follows:

"C:\Program Files\7-Zip\7z" a -p%_backup_passwd% -v8192m -t7z -m0=LZMA2 -mhe=on -mhc=on -mmt=16 -mx=2 -ms=off -r %_backup_target% %_backup_source%

In my folder structure I have folders:

C:\data\myname\mydata\lotsofstuff
C:\data\archive\myname\lotsofstuff

When %_backup_source% is given as "C:\data\myname", 7Z is matching to both of the directories above . It appears to be matching the last element of the path given, to all paths in the tree, rather than to the explicit path given.

It can be worked around by using "C:\data\myname*" but in this case, we lose the parent "myname" from the path specification of the stored files which is undesirable.

Also, if I change the directory name "C:\data\archive\myname" to one of:
"C:\data\archive\mynamex"
"C:\data\archive\mynam"
then, 7Z will no longer match it.

The behaviour appears unnatural, and, could have serious consequences, for example, accidentally archiving and distributing private content which was not intended to be within the specification of the pattern. Example: If someone has many projects, underwhich they all have "src" folder, then an attempt to archive "projectx\src" could inadvertently include "src" for lots of other projects also.

If for wildcard, we specify 'a path' surely, 7Z should only add files from the tree where the path is a match for the complete wildcard string, rather than some parsed elements of the wildcard string?

Perhaps there is some other logical explanation for this, but I don't see it!

Other than that, a fantastic piece of work which I have been using for some years.

Thanks/Regards,

-Carl.

[Carl Coffey]

In short: Should we treat "C:\path\subpath" as "C:\path<asterisk>\subpath\<asterisk>", probably not.</asterisk></asterisk>