I find that $validate(aaa \ bbb,_) returns not aaa _ bbb as expected, and as observed on versions until recently, but aaa\ bbb (note also the missing space before \).

Bug?

Also, $validate(aaa \ bbb,_)\t returns aaa \ bbb\t i.e. does not omit that space.

The backslash is a valid character for separating directories in a file path. The spaces before a backslash will be removed anyway, but I'll try to make this more consistent in the UI with a future release.

Kind regards,
Florian

> The backslash is a valid character for separating directories in a file path.

Backslash is an invalid character in a fileNAME, and since $validate() is described as "Remove invalid characters from filename", $validate() should remove backslash.

OK, I'll then update the documentation accordingly. Many users are using this function with file paths and a change would break all those scripts.

Fair enough! Thanks.

> I find that $validate(aaa \ bbb,_) returns ... aaa\ bbb (note ... the missing space
> Bug?
> $validate(aaa \ bbb,_)\t returns aaa \ bbb\t i.e. does not omit that space.

Any thoughts on specifically this missing space, Florian?

I want to throw in that ...

... a string like this:

" aaa \ bbb \ ccc "

... should be fixed to:

" aaa\ bbb\ ccc"

in order to be a valid path string for the disksystem.

DD.20090707.2033.CEST

Fixed.

Florian, I did a few tests - not all yet - and it looks good so far, but ...

... having this invalid string
"D:;\FOL*DER;\<FOLDER>\\\..\;A:?/*"

... then preview shows, e. g.
"D:\Programme\Mp3tag\D;\FOLDER;\;A.mp3"
Looks perfect cleaned and canonicalized.

But the dialog shows the non canonicalized path.
Click to view attachment

Please look into again.
... and try to suppress ascii values below 32 too.

Regards
Detlev

DD.20090713.12043.CEST

> ... having this invalid string
> "D:;\FOL*DER;\<FOLDER>\\\..\;A:?/*"

That's a cruel test... Well done!

> ... then preview shows, e. g.
> "D:\Programme\Mp3tag\D;\FOLDER;\;A.mp3"
> Looks perfect cleaned and canonicalized.

Likewise for me on your example:


> But the dialog shows the non canonicalized path.
> Click to view attachment

Here it can show a /mis/-canonicalized path


> Please look into again.

Let's not be too hasty here. The dialog's live preview has never shown the full path, just the part of the path corresponding to the Format String, validated. I think careful consideration is needed before changing the design intent.

In the example Detlev was referring to, the folder was already party canonicalized which was is also the case for the example chrisjj brought up. Thanks for pointing!

This should now also be addressed in the current Development Build.

I want to add ...

Found this, related to PowerShell, the list of invalid chars seems to be complete.

PS > "$($GetInvalidPathChars | foreach { [int]$_ } )"
34 60 62 124 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

PS > "$($GetInvalidFileNameChars | foreach { [int]$_} )"
34 60 62 124 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 58 42 63 92 47


Regarding my example string ...
From
D:;\FOL*DER;\<FOLDER>\\\..\;A:?/*
now cleaned and canonicalized to
D;\FOLDER;\;A.mp3

I noticed that the colon at position 2 was removed by Mp3tag v2.43c.
Does this work without failures under all circumstances that may come up in Mp3tag?

DD.20090726.2300.CEST

> Here it can show a /mis/-canonicalized path

(That was: Format string: d:\folder\..\file -> minipreview d:\folder\file.wma)

I think this is unstable behaviour because now I find a different result - non-canonicalisation:

Format string: d:\folder\..\file -> minipreview d:\folder\..\file.wma

(on V2.44)



Do you get this?