On 28.11.2015 17:41, Jilles Tjoelker wrote:
> Although cp -R will normally copy a fifo by calling mkfifo at the
> destination, it may open one if a regular file is replaced with a fifo
> between the time it reads the directory and it copies that file.
The sole fifo under /home here was mi/.licq/licq_fifo, created in 2003.
I echoed something into it (on the NFS-client side) and the cp-process
resumed.
I then performed a simple test:
1. Create a fifo in an NFS-exported directory and try to copy it with
the -R flag
mi@narawntapu:/cache/src (792) mkfifo /green/tmp/test
mi@narawntapu:/cache/src (793) cp -Rpn /green/tmp/test /tmp/
mi@narawntapu:/cache/src (794) ls -l /tmp/test
prw-r--r-- 1 mi wheel 0 29 лис 00:05 /tmp/test
The above worked fine.
2. Now, when I try to do the same thing via an NFS mount, I get the
same hang in fifoor:
root@aldan:ports/x11/kde4 (475) cp -Rpn /green/tmp/test /tmp/
load: 0.42 cmd: cp 38299 [fifoor] 1.15r 0.00u 0.00s 0% 1868k
So, the good news is, this is not ZFS' fault. The bad news is, there is
still a bug... Unless, of course, this is some known "feature" of the
NFS... Compare, for example, how stat(1) describes the same named pipe
from both machines:
Local FS:
92 74636334 prw-r--r-- 1 mi wheel 0 0 "Nov 29 00:05:51 2015" "Nov 29
00:05:51 2015" "Nov 29 00:05:51 2015" "Nov 29 00:05:51 2015" 16384 0
0 /green/tmp/test
NFS-client:
973143811 74636334 ?rw-r--r-- 1 mi wheel 4294967295 0 "Nov 29
00:05:51 2015" "Nov 29 00:05:51 2015" "Nov 29 00:05:51 2015" "Dec 31
18:59:59 1969" 16384 0 0 /green/tmp/test
That question-mark in the node-type (instead of the "p") is, I guess,
what confuses cp into trying to read from it instead of creating a fifo.
Should I file a PR? Thank you!
-mi
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[email protected]"
