On 04/03/2014 04:54 PM, Eric Blake wrote: > On 04/03/2014 09:03 AM, Dave Reisner wrote: >> On the initial call to copy_internal, we must use an invalid device >> number. As of linux 3.14, the mount table has shifted slightly, causing >> the initramfs filesystem to have a devno of 0. This is valid, but >> confuses cp when attempting to copy only a single filesystem (cp -x). >> Since dev_t is defined to be an integer type, we can simply use a >> negative value to identify the unknown device.
This kernel change seems like it might break lots of stuff. For example I did a simplistic search for "st_dev == 0" and noticed also: http://cgit.freedesktop.org/systemd/systemd/plain/src/readahead/readahead-common.c <shrug> Has the question been broached with the kernel folks about compat? > dev_t is defined as an integral type, but not necessarily a signed > integral type, and not necessarily a type as wide as int. Using -1 as a > sentinel might be okay, but if you do, you MUST use a cast for maximum > portability. > >> @@ -2434,7 +2434,7 @@ copy_internal (char const *src_name, char const >> *dst_name, >> } >> >> /* Decide whether to copy the contents of the directory. */ >> - if (x->one_file_system && device != 0 && device != src_sb.st_dev) >> + if (x->one_file_system && device != -1 && device != src_sb.st_dev) > > For example, this comparison may fail to do what you want if dev_t is > uint16_t (it will ALWAYS be false, since ((uint16_t)-1) != -1). Right, so: >> - if (x->one_file_system && device != 0 && device != src_sb.st_dev) >> + if (x->one_file_system && device != (dev_t) -1 && device != >> src_sb.st_dev) Given the age of these assumptions, I'd be as much worried about a clash with (dev_t)-1 as 0 TBH? Pádraig
