fix #19752 missing dup of fname field in phar_convert_to_other

[krakjoe]

No description provided.

[krakjoe]

maybe expect pestrndup, it is not necessary because the new phar object is calloced (so is_persistent is set 0), so that when phar_destroy_phar_data executes the string will be efree'd correctly.

[nielsdos]

I predict this will leak memory for sure. I think my approach that I posted in the thread is the right one. But as I said, I still have to verify this. Why try to race against me to make a PR though?

[krakjoe]

Why try to race against me to make a PR though?

There's no race, you are doing other things, said you "didn't have time", and the solution didn't appear correct to me.

[nielsdos]

I said I don't have time to double check now ;) Which means I will check it in the near future :P
Your solution isn't right because at one point the rename code will swap out the filename, so it will leak. The rename code can error out prior to the reassignment of the filename, which is why the test causes a crash. The rename code can also error out at a later point, which means it will have already assigned the new filename. In my solution: we detect in which case we are in and act accordingly.

[krakjoe]

Indeed rename does re-assign it, it will leak ...