A recent change (some time between 4.0.4 and 4.0.5) was made to the path handling in normalizeFileName. The old method used regular expressions to process '/' separators in path names. The new method uses File::Spec to process system-dependant path separators. As part of the processing, the function checks to see if the path is 'absolute'. Formally this was a check for a leading '/', now it is function from File::Spec. This information is then used at the end to construct a unix style path (a comment added in the new version does specify this). The problem is this: the routines are now using a system-indepedant method to identify 'aboslute path names', and then using this information to prepend a '/' (a unix convention). The result, on windows, is paths like '/c:/twiki/...', which get rejected by GNUWin32 grep, and I suspect most anything that works with windows paths.
I patched my own system by restoring the regular expression check for leading '/', since this is the correct check to see if one should prepend a slash afterwards. A better long term solution might be to use File::Spec throughout. Currently using File::Spec->catfile does not work because catfile uses '\' on windows and the downstream TWiki routines expect paths with '/'.
Complete environment: Windows 2003 server (inside VMWare), Apache 2.2.3 for windows, ActiveState
Perl 5.8, GNUWin32 grep
See also Item3241
This must be fixed for 4.1! Regrading as requirement.
I can't find any instance where the downstream twiki functions expect / separators, so I recoded to use File::Spec. If there are
sensitivities elsewhere in the code, we ought to identify and fix those as bugs, rather than getting this wrong.