jakub.ku...@oracle.com wrote:
I tested the patch on both intel and sparc platform and all seems to work
without any problem.
So I guess this can be closed as solved.
Thanks for checking; closing.
Thanks,
I tested the patch on both intel and sparc platform and all seems to
work without any problem.
So I guess this can be closed as solved.
best regards,
Jakub
On 5/30/19 1:46 AM, Paul Eggert wrote:
On 5/29/19 1:51 AM, jakub.ku...@oracle.com wrote:
somebody found this bug first at
On 5/29/19 1:51 AM, jakub.ku...@oracle.com wrote:
somebody found this bug first at 8.16, but this might have been there
for longer.
I looked into the revision history and it seems to have been introduced
long ago. I installed the attached further patch.
>From
Hi,
thanks for the patch - I tested it and all seems to work with both pipe
and <<, coreutils test suite is also happy.
Just a small correction on my part, somebody found this bug first at
8.16, but this might have been there for longer.
thanks
Jakub
On 5/28/19 10:46 PM, Paul Eggert
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
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
On 13/05/19 11:24, jakub.ku...@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
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
