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@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@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