Hi Peter,
Sure will fix my git config, sorry for that.
On Fri, 29 May 2026 at 13:47, Peter Krempa <[email protected]> wrote:
> On Fri, May 29, 2026 at 13:00:22 +0200, Radoslaw Smigielski via Devel
wrote:
> > LXC domains with long file-backed filesystem path fail to start when
> > the backing image path is longer than LO_NAME_SIZE (64 bytes, 63
characters plus NUL).
> > When long file path is passed, virFileLoopDeviceAssociate() ->
virStrcpy() fails
> > and user gets missleading error and domain fails to start.
> >
> > Example:
> >
> > <filesystem type='file' accessmode='passthrough'>
> > <driver type='loop' format='raw'/>
> > <source
file='/root/demoaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.raw'/>
> > <target dir='/'/>
> > </filesystem>
> >
> > To match losetup behavior we copy the path with virStrcpy() and allow
truncation
> > of lo_file_name only if needed, while still calling open() on the
unchanged path.
> > Finally log VIR_WARN when the path is expected to be truncated. But
still report
> > VIR_ERR_INTERNAL_ERROR for all other virStrcpy() failures.
>
> Umm, there are no other virStrcpy failures:
>
> /**
> * virStrcpy:
> *
> * @dest: destination buffer
> * @src: source buffer
> * @destbytes: number of bytes the destination can accommodate
> *
> * Copies @src to @dest. @dest is guaranteed to be 'nul' terminated if
> * destbytes is 1 or more.
> *
> * Returns: 0 on success, -1 if @src doesn't fit into @dest and was
truncated.
>
> so what you have there is effectively dead code.
Indeed, this would need to be removed.
> Another issue is that if you'll have:
>
> <filesystem type='file' accessmode='passthrough'>
> <driver type='loop' format='raw'/>
> <source
file='/root/someveeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeerylongpath/a.raw'/>
> <target dir='/'/>
> </filesystem>
> <filesystem type='file' accessmode='passthrough'>
> <driver type='loop' format='raw'/>
> <source
file='/root/someveeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeerylongpath/b.raw'/>
> <target dir='/'/>
> </filesystem>
>
> They'll be truncated to the same string.
So I tried to follow the same logic like losetup from util-linux uses to
handle long paths:
- takes the first 63 bytes of the absolute path
- no intelligent path shortening (like keeping the filename and
truncating middle)
- adds an asterisk at position 62 to indicate the name was truncated
lo->lo_file_name[LO_NAME_SIZE - 2] = '*'; // Position 62 gets '*'
lo->lo_file_name[LO_NAME_SIZE - 1] = '\0'; // Position 63 is null
terminator
Above indeed can result in non-unique or unhelpful loop device names in the
kernel's loop_info64 structure.
Question if we should mimic the same logic or imlement someting smarter.
Addint "*" before '\0' to indicate truncation would make it compatibile
with losetup behavior.
----------------------
< Tℏanks | Radek >
