GNU bug report logs - #35713
/dev/stdin problem in cp on Solaris

Previous Next

Full log

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

From: jakub.kulik <at> oracle.com
To: Pádraig Brady <P <at> draigBrady.com>, 35713 <at> debbugs.gnu.org
Subject: Re: bug#35713: /dev/stdin problem in cp on Solaris
Date: Tue, 28 May 2019 16:37:19 +0200

[Message part 1 (text/plain, inline)]

Hi,

I found a problem with your solution (even though maybe even more 
improbable). If I call it like this: *cp /dev/stdin b.txt < somedevice*, 
both stdin and the argument have the same type and copy still fails.

Possible solution might be to call stat when SAME_INODE fails and try it 
again (regular files and folders can be excluded).

Jakub

On 5/27/19 12:59 PM, jakub.kulik <at> oracle.com wrote:
> Well, I guess that while improbable, that can happen. I am only 
> thinking whether is it possible that both stat and fstat return 
> different devices with same S_IFMT but I am not sure about that.
>
> Anyway I tried it with your suggestion and for my use case it works as 
> well.
>
> regards,
> Jakub
>
> On 5/26/19 2:25 PM, Pádraig Brady wrote:
>> On 13/05/19 11:24, jakub.kulik <at> oracle.com wrote:
>>> Hi,
>>>
>>> We found out that the following simple command fails on Solaris with:
>>>
>>>    cat srcfile.txt | /usr/gnu/bin/cp /dev/stdin dstfile.txt
>>>    cp: skipping file '/dev/stdin', as it was replaced while being 
>>> copied
>>>
>>> I found that problem is with SAME_INODE macro. It accepts two
>>> structures, one from stat and another from fstat function. On Solaris,
>>> each of these can return a different thing. While stat returns
>>> information about the /dev/fd/0 file itself (linked by /dev/stdin),
>>> fstat knows much more from the file descriptor and returns info about
>>> the pipe that is being used. That results in SAME_INODE failing.
>>>
>>> This happens in both Coreutils 8.30 and 8.31 (both intel and sparc) but
>>> it looks like it was seen first in 8.16.
>>>
>>> The easiest fix to this issue I came up with is to disable SAME_INODE
>>> validation for special devices and pipes (as they won't be moved
>>> anyway)
>> But what if a file is replaced with a character special device for 
>> example?
>> How about doing something like the following before the SAME_INODE 
>> check?
>>
>> #if _solaris
>> if (S_IFMT(source_desc) != S_IFMT(src_open_sb)
>>    stat(src_name, &src_open_sb);
>> #endif
>>
>> cheers,
>> Pádraig

[Message part 2 (text/html, inline)]

Previous Next

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