Comment 8 for bug 1830024

Hi,

After analyzing the `unitl-linux` of Ubuntu LTS, I've seen that the aforementioned patch with the fix is included.
However, the attempt to reproduce the failure shows that the `/(deleted)` prefix is attached to the root filed of the mount-info entry. Which made me think that what we need to focus on is to check how snapd itself is affected when parsing mountinfo records that reflect the status of broken link.

I've reproduced the failure once again on a VM and used snapd osutil package to load the "corrupted" moountinfo data, the same way as snapd does. Then, I printed the contents of the []*MountInfoEntry in JSON format (please see the attached reproduced_MountInfoEntry_structure.json). As one can see, snapd succeeded to process such file without crashing, and similar to reproduced results in command-line, the output is affected the way that the `/(deleted)` prefix is attached to the root filed. This means that we are not at risk of crashing due to this phenomena in the file.
Taking into account that this data doesn't crash snapd, it worth checking how this field is used by snapd, and currently there is no occurrence within the snapd code where this field is used rather then simply compared to '/'.

All this makes me to conclude that this doesn't pose any risks to at least go-part of snapd.

Kind regards,
Arseniy