Hi all,
can somebody explain following:
mkdir m1
cat m1 > m2
The above cat creates a short file(208 bytes) and no error.
Is this a bug or a feature?
Here is another strange example:
mkdir m1
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?
Kind Regards
Michael
Michael Tasche wrote:
Hi all,
can somebody explain following:
mkdir m1
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:
mkdir m1
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 .”).
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”).
John Garvey schrieb:
Michael Tasche wrote:
Hi all,
can somebody explain following:
mkdir m1
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:
mkdir m1
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 .”).
/dev/hd0t79 /
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.
-Michael
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”).
John Garvey schrieb:
Michael Tasche wrote:
Hi all,
can somebody explain following:
mkdir m1
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.
I understand, so everything is OK for the resource manager.
But a posix conform “cat” utility should produce an error message, right?
-Michael
Here is another strange example:
mkdir m1
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 .”).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”).
Michael Tasche wrote:
John Garvey schrieb:
Hi all,
can somebody explain following:
mkdir m1
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.
I understand, so everything is OK for the resource manager.
But a posix conform “cat” utility should produce an error message, right?
I don’t think so; unlike cp which explicitly spells out the various
scenarios, cat says nothing other than “… shall read the files in
sequence, and shall write their contents …”; specs for read() do
not define what the behaviour on a directory is other than say that
EISDIR is a valid error if “… the implementation does not allow the
directory to be read using read() …”. I see some systems/coreutils
do go the EISDIR way, but this is not mandatory; our resmgrs do
support reading of a directory as providing struct dirent output.