Comment 19 for bug 1647485

Note: the workaround patch from comment 17 *will not* conflict with whatever fix is implemented upstream. The patch changes *only* the NVMe rules to force whitespace replacement. If upstream changes the default behavior, to replace whitespace, then this workaround patch becomes redundant/unneeded, but it will not conflict.

The issue is the behavior of udev for SYMLINK values, depending on the "string_escape" option setting for each SYMLINK rule. There are 3 possible settings, 1) unset (the default), 2) "none", and 3) "replace". As expected, when set to "none", udev does not replace any characters (neither whitespace nor any other characters) in the SYMLINK value; and when set to "replace", udev replaces all whitespace, as well as invalid characters, with underscores. The default behavior (when unset) is what may change upstream - currently, it replaces all invalid characters but *does not* replace whitespace. This is a problem for SYMLINK values, since the SYMLINK string is a whitespace-separated list of strings. No rules that are included with udev currently want this behavior, but there may be some custom udev rules that expect it. The NVMe rules do not expect or want it. For reference, the NVMe udev rules are:

SYMLINK+="disk/by-id/nvme-$env{ID_SERIAL}"
SYMLINK+="disk/by-id/nvme-$env{ID_SERIAL}-part%n"

these rules expect one, and only one, symlink to be created for each new NVMe drive (or NVMe partition) that is detected. Under no circumstances do these rules ever want multiple symlinks created for a single execution of the rule. So this workaround, to set "string_escape=replace" only for these 2 NVMe rules, is appropriate. If the default behavior upstream is changed later, so that any whitespace in the ID_SERIAL string is replaced when "string_escape" is unset, then the behavior of udev for these specific rules will be identical whether "string_escape" is unset or set to "replace", and so at that point this workaround patch can be left or reverted, as the udev behavior will be identical either way. Until then, this workaround patch is needed for the correct behavior.