Subject: Re: bug#35713: /dev/stdin problem in cp on Solaris

From: [email-masked]
Date: Mon, 27 May 2019 12:59:58 +0200

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, [email-masked] 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