lkml.org 
[lkml]   [2011]   [Jan]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectLOOP_GET_STATUS(64) truncates pathnames to 64 chars (was Re: Bug in mkfs.btrfs?!)
/*
* CC'd to linux-kernel in case they have any feedback on this.
*
* Long thread, trying to work out why mkfs.btrfs failed to
* make a filesystem on an encrypted loopback mount called
* /dev/loop2. Cause turned out to be mkfs.btrfs calling
* LOOP_GET_STATUS to find out if the block device was mounted
* and getting a truncated device name back and so it later
* fails when lstat() is called on the truncated device path.
*
* The long device name for the encrypted loopback mount was
* because /dev/disk/by-id/$ID was used when Felix created it
* to cope with devices moving around.
*/

On 25/01/11 00:01, Felix Blanke wrote:

> you were talking about the LOOP_GET_STATUS function. I'm not
> quite sure where does it came from. Is it part of the kernel?
> Or does it come from the util-linux package?

It's in the kernel, and there is both LOOP_GET_STATUS (old
implementation) and LOOP_GET_STATUS64 (new implementation).

They return structures called loop_info and loop_info64
respectively and both are defined in include/linux/loop.h .

Sadly in both cases the lengths of paths are defined to be
LO_NAME_SIZE which is currently 64 and hence either
implementation will cause the problematic:

lstat("/dev/disk/by-id/ata-INTEL_SSDSA2M160G2GC_CVPO939201JX160AGN-par",
0x7fffa30b3cf0) = -1 ENOENT (No such file or directory)

I've CC'd this to the LKML in case they have any feedback on
this apparent problem with the API.

cheers,
Chris
--
Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC


\
 
 \ /
  Last update: 2011-01-25 01:25    [W:0.067 / U:1.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site