[persisted scope] fix: handle recursive directory correctly

[OrIOg]

Apparently, I must have broken something while wanting to change #32 to not use change the data structure nor a git version of Tauri.

But here we are.

---

PR for fixing #25 by calling the calling specific function for file/directory and handling recursion.

We can't just directly pass saved paths/patterns as recursive one such as "/my/path/**" as they will be escaped to "/my/path/[*][*]" when allowed in the scope.

We need to check on them if they are files/directories/recursive directories versions of the pattern and then edit them if necessary.

[FabianLars]

First of all, thanks for rewriting it for the x-th time 😅 I really like this one's approach!

As far as i can see, it's working nicely for recursive dirs, but "normal" dirs are missing the removal of the trailing *.

Also, since this is one of the very few plugins released to crates.io we will also need a changefile before we can merge it.

(TIL that we use glob patterns for saving dirs at runtime too, i thought we only do that for tauri.conf.json scopes...)

[OrIOg]

I'll look at it this evening, thanks for taking the time to check on it.

Might have been hyperfocused on the "**" 😅

---

Thanks for the reminder about the change file

[OrIOg]

Ok, that is one more step in the good direction.

I did discover another problem,

Let's imagine a multi-level bugged path in .persisted-scope file containing:
/my/super/path/[*]/[*]
it will be fixed to:
/my/super/path/*/*
then my fix will only change it to:
/my/super/path/*
while it should be:
/my/super/path/

I should be able to in somewhat the same way as you have done fix_pattern with a loop/recursion

Should be fixed now.
Edit:
Was it really a thing in the first case? Maybe it wasn't necessary. Need to rethink about this

---

Edit:

Another point, what if we had a file/path with [*] in it, but it's intended.
That's something to think about with the fix_pattern. Even if it's a supposed to be temporary, and that it is a strange way to name something.

Test:
Linux: Possible
Windows: No, maybe with WSL ?
Mac: I think ? Need verification.

So, do we need to escape it in some way ?

[FabianLars]

Was it really a thing in the first case? Maybe it wasn't necessary. Need to rethink about this

i don't think so. This pattern will only be used in tauri.conf.json which already allows/denys the paths itself so i don't think this plugin should be concerned about /*/* or similar 🤔

Another point, what if we had a file/path with [*] in it, but it's intended.

I personally don't think this would be a real world issue. But even if, we can only handle that by removing/rewriting the current pattern fixer. So something we can keep in mind if we change the file version or something but i'd rather not remove the fix without some other kind of safeguard (like not reading the old file at all) since the fix was added to prevent OOM crashes (which weren't rare).

[OrIOg]

i don't think so. This pattern will only be used in tauri.conf.json which already allows/denys the paths itself so i don't think this plugin should be concerned about // or similar 🤔

Yeah... That's what I realised this morning...
Well, I'll check it just in case and remove if it's indeed useless.

And just realised that the yarn.lock was pushed..

[OrIOg]

I think it is done 😶

[FabianLars]

Looks awesome! gonna do some last testing tomorrow morning and will merge it asap then :)

[FabianLars]

Thanks again!

[vasilvestre]

This got releases in v1 and v2?

[FabianLars]

yes