`@ importing` filters files doesn't work for relative paths

Bug
#1

I’m trying (for the first time only now, shame on me) to use Filters just got a big upgrade: @import files.

In .duplicacy/filters i have a single line:

@/duplicacy-utils/filters/filters_general_usage

which is a relative path to my general filters file.

When I run backup

PS C:\duplicacy-repositories\tbp-fusion> .\.duplicacy\z.exe -d -log backup
2020-01-10 09:03:39.759 INFO STORAGE_SET Storage set to G:\My Drive\backups\duplicacy
[...]
2020-01-10 09:03:41.225 INFO BACKUP_INDEXING Indexing C:\duplicacy-repositories\tbp-fusion
2020-01-10 09:03:41.226 INFO SNAPSHOT_FILTER Parsing filter file \\?\C:\duplicacy-repositories\tbp-fusion\.duplicacy\filters
2020-01-10 09:03:41.226 INFO SNAPSHOT_FILTER Parsing filter file \\?\UNC\?\C:\duplicacy-repositories\tbp-fusion\.duplicacy\duplicacy-utils\filters\filters_general_usage <- This path is correct, except for the "\\?\UNC\?\" part
2020-01-10 09:03:41.228 DEBUG REGEX_DEBUG There are 0 compiled regular expressions stored
2020-01-10 09:03:41.228 INFO SNAPSHOT_FILTER Loaded 0 include/exclude pattern(s)
2020-01-10 09:03:41.228 DEBUG LIST_ENTRIES Listing

it loads 0 patterns, even though the imported path is resolved correctly. It does have a weird header though: \\?\UNC\?\.

If I set the full path instead of relative in the filters file, so the content becomes

@C:/duplicacy-repositories/tbp-fusion/.duplicacy/duplicacy-utils/filters/filters_general_usage

Then everything works ok:

PS C:\duplicacy-repositories\tbp-fusion> .\.duplicacy\z.exe -d -log backup
2020-01-10 09:26:06.327 INFO STORAGE_SET Storage set to G:\My Drive\backups\duplicacy
[...]
2020-01-10 09:26:07.763 INFO BACKUP_START Last backup at revision 4 found
2020-01-10 09:26:07.763 INFO BACKUP_INDEXING Indexing C:\duplicacy-repositories\tbp-fusion
2020-01-10 09:26:07.765 INFO SNAPSHOT_FILTER Parsing filter file \\?\C:\duplicacy-repositories\tbp-fusion\.duplicacy\filters
2020-01-10 09:26:07.771 INFO SNAPSHOT_FILTER Parsing filter file C:/duplicacy-repositories/tbp-fusion/.duplicacy/duplicacy-utils/filters/filters_general_usage <- this is correct, and without the weird header
2020-01-10 09:26:07.773 DEBUG REGEX_STORED Saved compiled regex for pattern "(?i)(^|/)\.git/", regex=&regexp.Regexp{expr:"(?i)(^|/)\\.git/", prog:(*syntax.Prog)(0xc006075a40), onepass:(*regexp.onePassProg)(nil), numSubexp:1, maxBitStateLen:21845, subexpNames:[]string{"", ""}, prefix:"", prefixBytes:[]uint8(nil), prefixRune:0, prefixEnd:0x0, mpool:0, matchcap:4, prefixComplete:false, cond:0x0, longest:false}
[...]
2020-01-10 09:26:08.132 INFO SNAPSHOT_FILTER Loaded 198 include/exclude pattern(s)

it loads all the patterns, and it does NOT have that weird header: \\?\UNC\?\.

#2

I remember when I started using the “filter @import” I also had problems with relative paths, although at the moment I don’t remember exactly what those problems were.

So I always used it with absolute paths.

1 Like
#3

Deiced to check the code (I have some interest in learning :d: codebase).
There seems to be a bug how code joins path components for Windows path - joinPath function receives path returned by os.Getwd() which will be in namespaces format \\?\C:\duplicacy... and pre-pends it with its own string \\?\. I believe this is designed to process normal path strings. Then it checks if this was UNC name by checking the result string for prefix \\?\\\ - which it now does - and converts it to UNC namespace path by replacing that prefix with new one \\?\UNC\ - which essentially breaks otherwise good path :weary:
The logic in joinPath is awkward, this needs to be rewritten to check for UNC path before prepending anything… OTOH, if joinPath is used mostly with normal path strings, ProcessFilterLines can be modified to return prefix from path returned by os.Getwd(), but I’d consider this a hack instead of good code :smile:

1 Like