John Garvey schrieb:
Michael Tasche wrote:
can somebody explain following:
cat m1 > m2
The above cat creates a short file(208 bytes) and no error.
Is this a bug or a feature?
This is deliberate; read() of a directory is readdir(); your
m2 file will contain ‘struct dirent’ output (see <dirent.h>)
for the ‘.’ and ‘…’ entries of that directory.
Here is another strange example:
ln -s m1 m2
cp m1 m3
cp m2 m4
The above cp m1 m3 creates the correct error message.
The above cp m2 m4 creates the short file and/or hangs.
(You cannot kill the cp process)
What is going on here?
For me this makes a file containing the struct dirent output
(like the original example, of reading a directory) - what is
your target filesystem? (“df -g .”).
df -g .
Blocks: 8067072 total 7869872 avail [512-byte blocks]
Files : 0 total 0 avail
Type : qnx4
Flags : 00000100 [32bit]
I have the same behaviour on QNX4 filesytems and on nfs mounted
filesystems(Wrong behabviour of cp).
The additional hang of cp and the whole filesystem I can only reproduce
on a customer system(6.3sp2) at the moment.
I think this is a bug though, and the correct behaviour would
be both behave the same (POSIX says “If source_file is a file
of type symbolic link: if neither the -R nor -r options
were specified cp shall take actions based on the type and
contents of the file specified by the symbolic link and not
by the symbolic link itself”) with that behaviour being the
error message (POSIX “If source file is of type directory,
neither -R nor -r was specified, cp shall write a
diagnostic message to standard error”).