[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: jakub . kulik
Subject: bug#35713: /dev/stdin problem in cp on Solaris
Date: Tue, 28 May 2019 16:37:19 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0


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).


On 5/27/19 12:59 PM, address@hidden 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.


On 5/26/19 2:25 PM, Pádraig Brady wrote:
On 13/05/19 11:24, address@hidden wrote:

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
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);


reply via email to

[Prev in Thread] Current Thread [Next in Thread]