/dev/bus/usb/X/Y fall back to zero-padding

[sladen]

Note that this report has come via a user, who reported an issue to the usbmuxd/libiphone list; libusb is used in this case to access various Apple iPhone/iTouch devices. It involves the zero-padding (or not) of nodes under /dev/bus/usb/...

The user reports that they were using a Slackware machine with libusb-1.0.6 installed; the usbmuxd daemon receives a connection failure, which was eventually debugged down to failing because there was an attempt to open:

/dev/bus/usb/002/017

instead of:

/dev/bus/usb/2/17

The lines in question are both in libusb/os/linux_usbfs.c:

snprintf(path, PATH_MAX, "%s/%03d/%03d", usbfs_path, dev->bus_number,
snprintf(path, PATH_MAX, "%s/%d/%d", usbfs_path, dev->bus_number,

and:

snprintf(dirpath, PATH_MAX, "%s/%03d", usbfs_path, busnum);
snprintf(dirpath, PATH_MAX, "%s/%d", usbfs_path, busnum);

According to:

​http://lists.freedesktop.org/archives/hal/2006-September/006151.html

it appears that the difference is whether the enumuration data
was sourced via '/dev/bus/usb' or '/proc/bus/usb' (?).

Ideally libusb should fallback to trying both alternatives and check that the relevant path really does exist before trying to open it.

[dsd]

This is a dup of #25. Can you follow up with slackware to see if this is intentional, and why?

I think it's a slackware bug. Ubuntu, Gentoo and Fedora use "zero padding"

[stuge]

Please reopen #25 at http://libusb.org/ticket/25 when more information becomes available. Thanks!