P4
Test
java/nio/file/Files/walk_file_tree.sh
fails because sometimes it creates link in subdirectory pointing to this directory, e.g.:
ls -la /tmp/name940805575/dir1/dir5/dir12/link1 /tmp/name940805575/dir1/dir5/dir12
lrwxrwxrwx 1 vmsqe-robot uucp 34 2010-02-16 14:11 /tmp/name940805575/dir1/dir5/dir12/link1 -> /tmp/name940805575/dir1/dir5/dir12/
/tmp/name940805575/dir1/dir5/dir12:
total 8
drwxrwxr-x 2 vmsqe-robot uucp 4096 2010-02-16 14:11 ./
drwxrwxr-x 5 vmsqe-robot uucp 4096 2010-02-16 14:11 ../
-rw-rw-r-- 1 vmsqe-robot uucp 0 2010-02-16 14:11 file14
-rw-rw-r-- 1 vmsqe-robot uucp 0 2010-02-16 14:11 file22
-rw-rw-r-- 1 vmsqe-robot uucp 0 2010-02-16 14:11 file28
-rw-rw-r-- 1 vmsqe-robot uucp 0 2010-02-16 14:11 file34
-rw-rw-r-- 1 vmsqe-robot uucp 0 2010-02-16 14:11 file45
lrwxrwxrwx 1 vmsqe-robot uucp 34 2010-02-16 14:11 link1 -> /tmp/name940805575/dir1/dir5/dir12/
The test compares output of Java program with output of find. In this particular case, find does not display '/tmp/name940805575/dir1/dir5/dir12/link1', but issues warning instead:
find: File system loop detected; `/tmp/name940805575/dir1/dir5/dir12/link1' is part of the same file system loop as `/tmp/name940805575/dir1/dir5/dir12'.
From manpage on find:
The POSIX standard requires that find detects loops:
The find utility shall detect infinite loops; that is, entering a previously visited directory that is an ancestor of the last file encountered. When it
detects an infinite loop, find shall write a diagnostic message to standard error and shall either recover its position in the hierarchy or terminate.
GNU find complies with these requirements. The link count of directories which contain entries which are hard links to an ancestor will often be lower than they oth¿
erwise should be. This can mean that GNU find will sometimes optimise away the visiting of a subdirectory which is actually a link to an ancestor. Since find does
not actually enter such a subdirectory, it is allowed to avoid emitting a diagnostic message. Although this behaviour may be somewhat confusing, it is unlikely that
anybody actually depends on this behaviour. If the leaf optimisation has been turned off with -noleaf, the directory entry will always be examined and the diagnostic
The test either needs to be changed not to create such links to parent directory or to conform to find behavior.
java/nio/file/Files/walk_file_tree.sh
fails because sometimes it creates link in subdirectory pointing to this directory, e.g.:
ls -la /tmp/name940805575/dir1/dir5/dir12/link1 /tmp/name940805575/dir1/dir5/dir12
lrwxrwxrwx 1 vmsqe-robot uucp 34 2010-02-16 14:11 /tmp/name940805575/dir1/dir5/dir12/link1 -> /tmp/name940805575/dir1/dir5/dir12/
/tmp/name940805575/dir1/dir5/dir12:
total 8
drwxrwxr-x 2 vmsqe-robot uucp 4096 2010-02-16 14:11 ./
drwxrwxr-x 5 vmsqe-robot uucp 4096 2010-02-16 14:11 ../
-rw-rw-r-- 1 vmsqe-robot uucp 0 2010-02-16 14:11 file14
-rw-rw-r-- 1 vmsqe-robot uucp 0 2010-02-16 14:11 file22
-rw-rw-r-- 1 vmsqe-robot uucp 0 2010-02-16 14:11 file28
-rw-rw-r-- 1 vmsqe-robot uucp 0 2010-02-16 14:11 file34
-rw-rw-r-- 1 vmsqe-robot uucp 0 2010-02-16 14:11 file45
lrwxrwxrwx 1 vmsqe-robot uucp 34 2010-02-16 14:11 link1 -> /tmp/name940805575/dir1/dir5/dir12/
The test compares output of Java program with output of find. In this particular case, find does not display '/tmp/name940805575/dir1/dir5/dir12/link1', but issues warning instead:
find: File system loop detected; `/tmp/name940805575/dir1/dir5/dir12/link1' is part of the same file system loop as `/tmp/name940805575/dir1/dir5/dir12'.
From manpage on find:
The POSIX standard requires that find detects loops:
The find utility shall detect infinite loops; that is, entering a previously visited directory that is an ancestor of the last file encountered. When it
detects an infinite loop, find shall write a diagnostic message to standard error and shall either recover its position in the hierarchy or terminate.
GNU find complies with these requirements. The link count of directories which contain entries which are hard links to an ancestor will often be lower than they oth¿
erwise should be. This can mean that GNU find will sometimes optimise away the visiting of a subdirectory which is actually a link to an ancestor. Since find does
not actually enter such a subdirectory, it is allowed to avoid emitting a diagnostic message. Although this behaviour may be somewhat confusing, it is unlikely that
anybody actually depends on this behaviour. If the leaf optimisation has been turned off with -noleaf, the directory entry will always be examined and the diagnostic
The test either needs to be changed not to create such links to parent directory or to conform to find behavior.