[amail80]

SaveFavoriteVolumes writes the label of a favorite volume into an attribute as is, while the path is escaped with XmlQuoteTextW. XmlGetAttributeText and XmlGetNodeText take the first > for the end of the element, so after a restart a favorite volume whose label contains < or > loses its path, label and options:

• with the label A > B, the path is read as B" readonly="1">C:\Vols\work.hc, and the label and the read-only option are empty;
• with the label Old <2024>, the path is read as empty.

This PR:

• writes a label that contains &, < or > escaped and marked with labelEscaped="1", and decodes only marked labels. Earlier versions wrote labels as is, and their labels, which have no marker, are read as before, including text such as <. Labels without these characters are written exactly as before;
• writes the marker and the label after all other attributes, so that text in a label cannot be taken for another attribute;
• adds XmlFindTagEnd, which skips > inside attribute values, and uses it in XmlGetAttributeText and XmlGetNodeText, so that favorites written by earlier versions with < or > in a label load with their label, path and options. The translators attribute of the Hungarian language file, which contains >, is now read as well;
• escapes the label into a string without a fixed size and reads it into a buffer as long as its start tag, and rejects a label longer than the 1023 units the Organize Favorite Volumes dialog keeps, together with its favorite, without affecting the other favorites.

An earlier version reading a file written by this one ignores the marker and shows escaped labels with the escapes, such as R&D. If it saves the file, the escaped text becomes the label.

Testing

Xml.c and the label code of SaveFavoriteVolumes and LoadFavoriteVolumes from this branch, built on Linux:

• Written and read back by this version, saved again and read again, with the read-only option: Work, A > B, Old <2024>, R&D, x < y, R&D labelEscaped=, Archive readonly=, 205, 410 and 1023 &, and 1023 Cyrillic letters all come back unchanged, read-only.
• Files written by master: A > B and Old <2024> now load with label, path and read-only option. The other labels load as master loads them, except that 1023 Cyrillic letters come back in full instead of empty.
• A label of 1023 units loads. Labels of 1024 and 70,000 units are rejected with their favorite, the favorites before and after them load, and Utf8StringToWide is never given more than 5,115 units, well below its limit.
• All 74,983 elements of the 43 language files read the same with the old and the new Xml.c functions, except the Hungarian translators attribute.

Windows 11, with this build: R&D labelEscaped= stays the same after a restart and another save, Archive readonly= keeps the read-only option, favorites written as earlier versions do with A > B or Old <2024> in the label load with their label, path and read-only option, A > B <2024> & co with the read-only option is kept, and the language dialog shows the Hungarian translators.

[idrassi]

Thanks for tracking this down. The escaping fixes the reported parsing problem, but I found two cases that need addressing before we merge.

The first concerns existing favorites files. A label such as x < y, saved by an older version, becomes x < y when loaded with this change. Older versions wrote labels verbatim, so applying UnquoteXmlText unconditionally changes labels that previously worked. The round trip test covers the new writer followed by the new reader; it doesn't cover loading a file written by an older version. Please preserve the interpretation of existing labels. An explicit encoding marker for newly written labels would let the reader distinguish them without guessing.

There's also a buffer size problem. A label containing 205 ampersands expands to 1025 bytes, which exceeds the reader's 1024 byte buffer. XmlGetAttributeText fails before decoding, and the label comes back empty. With 410 ampersands, the escaped text exceeds the writer's 2048 character buffer, and the label attribute is silently omitted. Both inputs fit within the length currently accepted by the dialog.

Please account for the expanded representation in the writer and reader, and don't silently discard the label if escaping fails.

These cases just need to be handled so existing favorites don't lose their labels after an upgrade.

[amail80]

Thanks for the careful review, both points are right. I reproduced them with the first revision: a label written by an earlier version as x < y was read as x < y, a label of 205 ampersands was written but read back empty, and one of 410 was left out of the file.

ef7706a changes this:

• A label that escaping changes, one with &, < or >, is written escaped and marked with labelEscaped="1", and LoadFavoriteVolumes decodes only marked labels. Labels written by earlier versions have no marker and are read as before, x < y included. Labels without these characters are written exactly as before, without the marker.
• The label is escaped into a wstring by QuoteXmlText, which makes the same three replacements as XmlQuoteTextW, so the writer has no buffer to overflow and nothing to drop.
• The reader reads the label into a buffer as long as the start tag that holds it, so any label in the file fits, escaped or not. This also keeps long labels that were lost before: with master, a label of more than 1023 bytes in UTF-8, such as 512 Cyrillic letters, comes back empty after a restart.

One limit remains with earlier versions reading a file written by this one: they ignore the marker, so they show escaped labels with the escapes, and they still cannot read a label longer than 1023 bytes. If such a version saves the file, the escaped text becomes the label.

Checked on Windows 11 with this build: a favorites file edited to label="x < y" without the marker shows x < y in Organize Favorite Volumes, as earlier versions do. A label of 410 & is written as 410 & with the marker and is still there after a restart and another save. work is written as label="work", without the marker. A > B <2024> & co with the read-only option keeps its label, path and option after a restart.

[idrassi]

Thanks for the quick follow up.

I have left three inline comments.

[idrassi]

Could you put the marker before the label, and preferably write the label after the other attributes? XmlGetAttributeText stops at the first matching text even when it sits inside another attribute value. With the label R&D labelEscaped=, this code writes:

label="R&D labelEscaped=" labelEscaped="1"

The reader treats the text inside label as the marker. Since that value doesn't fit in the two byte buffer, the marker stays unset and the label is read as R&D labelEscaped=. Each later save adds another amp;. I reproduced this with both ordinary favorites and system favorites.

Writing the real attributes first and label last fixes this case with the current reader. It also keeps a label such as Archive readonly= from hiding the real readonly="1" attribute. That second case currently reloads as writable, so the order matters beyond the new marker.

[idrassi]

Using the first > here means the new reader still can't recover affected files that an older VeraCrypt has already written. At this head, an unmarked A > B label still moves part of the tag into the path and clears readonly. Old <2024> still comes back empty.

Could this locate the closing > outside quoted values? The Unix parser already has FindTagEnd for this. Keeping an unmarked label undecoded would still preserve the older x < y behavior that the marker is meant to protect.

[amail80]

Thanks, all three are addressed in 7e11f86.

• The marker and the label are now written after all other attributes, the marker first. With the label R&D labelEscaped=, the file has labelEscaped="1" label="R&D labelEscaped=", and the label stays the same across saves. Archive readonly= keeps the read-only option.
• XmlGetAttributeText and XmlGetNodeText now find the end of the start tag with a new XmlFindTagEnd, which skips > inside attribute values, and the node text starts after that end. Files written by earlier versions with A > B or Old <2024> in a label now load with their label, path and options. Unmarked labels are still not decoded. I read every element of the 43 language files with the old and the new functions: the only difference is the translators attribute of the Hungarian file, which contains >. It was read as empty and is now shown in the language dialog.
• A label longer than the editor's 1023 units is rejected with its favorite before Utf8StringToWide, and the favorites before and after it load normally. SetFavoriteVolume uses the same constant.

One case remains for files written by earlier versions, where the label comes before the other attributes: a label such as Archive readonly= in such a file still hides the real attribute, as it does in master. That would need XmlGetAttributeText to skip attribute values when it searches for a name. I can add that here or separately, if you'd like.

Checked on Windows 11 with this build: R&D labelEscaped= is written as labelEscaped="1" label="R&D labelEscaped=" and stays the same after a restart and another save; Archive readonly= keeps the read-only option; a line written as earlier versions do, with label="A > B" or label="Old <2024>" before readonly="1", loads with its label, path and read-only option; and the language dialog shows the Hungarian translators, which it showed empty before.

[idrassi]

Thanks for the update. Looks good to me now.