Anthony Vanelverdinghe

@rgrunber I'm no longer able to reproduce with the same string in the same file (I don't remember the exact spot). When it happens again I'll share the file exactly...

@rgrunber here's an example with the source code exactly as it was (I marked the cursor position with ``). However, as expected, once it has occurred, it doesn't reproduce anymore:...

This is on Windows 11 24H2 (26100.3037). Both extracting * by right-clicking in File Explorer and choosing `Extract All...` * by running `wsl tar xzf d2-v0.6.8-windows-amd64.tar.gz` gives the same results.

For the record, Windows 11 has built-in support for .tar.gz Edit: PowerShell's `Expand-Archive` currently lacks support for it though, so switching to .zip would be helpful in this regard

As mentioned above, this is a regression from 3.4.0, not an enhancement. The root cause is that, at least on Windows, `File::delete` deletes read-only files successfully, whereas `Files::delete` does not....

Just to be clear: I'm all in favor of migrating to `Path`. I'm just arguing that this issue is a severe regression and that we should revert the problematic commits...

This issue was filed just 10 days after the release of 3.4.1, while I doubt there have ever been complaints about the deletion of read-only files in the decades before...

Context is everything. Oracle's assessment of the situation and their chosen path forward makes perfect sense to me. At the same time, introducing a `force` parameter with a default value...

Thanks for the quick response. When I test it on regex101, the subject matches. The issue seems to be with the "Re: ". With the add-on in Thunderbird: `.*RFR: 8343306:...

`/: RFR: 8321500:/` does not match either, but `^RFR: 8321500:.*value$` does match. So FiltaQuilla acts as if the `Re: ` is not there at all.