GNU bug report logs - #17179
[PATCH] cp: use an invalid dev_t for an unknown device

Previous Next

Package: coreutils;

Reported by: Dave Reisner <dreisner <at> archlinux.org>

Date: Thu, 3 Apr 2014 15:40:02 UTC

Severity: normal

Tags: patch

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


Message #11 received at 17179 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: Dave Reisner <dreisner <at> archlinux.org>, thomas <at> archlinux.org,
 17179 <at> debbugs.gnu.org
Subject: Re: bug#17179: [PATCH] cp: use an invalid dev_t for an unknown device
Date: Thu, 03 Apr 2014 17:38:12 +0100
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







This bug report was last modified 11 years and 55 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.