Looking at the new rc1, there is an issue with the delete wildcard code. An explode is performed on the * and then everything before the * is used for a file_scan_directory call.

The issue arises in that the file being looked for originally had a replace done on it to make the file name safe for windows. This replacement needs to be performed on the delete too so that correct matches will be made.

In our case, the menus were not being regenerated correctly.

See the attached patch.

CommentFileSizeAuthor
delete-wildcard-file-engine.patch683 bytesharking

Comments

JirkaRybka’s picture

This have still some problems:

- Filenames with the current naming pattern are generally not necessarily unique (all bad characters replaced by uniform '-'), so the wildcard deletion is still unreliable.

- Duplicated escaping code is likely to be broken by further patches. I would prefer the filename escaping part to be abstracted to a separate function, to give always consistent results.

- The {$look_for[0]} string is used directly as a part of ereg() regex inside file_scan_directory(), so we're still unsafe with this escaping. Unfortunately, I seem unable to find any documentation on ereg(), because it's long deprecated now.

I re-rolled my patch at #578522: File engine: Performance, filenames, and other cleanup to have this fixed - it already fixes the first, and the last point, so it's much easier to fix the remaining one in context of that patch, than from scratch here. It would be great if you tested that one regarding this additional fix. I'm going to test it on my site, too.

andypost’s picture

Status: Needs review » Closed (duplicate)