Regarding "/bin/cp : will not create hard link" message

[Minoru Asano]

Hello,

At the customer site, when he copy some data from NFS server to another NFS server
the following message appeared:

[ENVIRONMENT]
RHEL AS 3 update6
NFS server : NetApp server x 2

----+--------------+---------+----------------
NetApp(/oradata) RHEL NetApp(/oraback)

[MESSAGE]
/bin/cp : will not create hard link 'dir1' to directory 'dir2'
dir1:/oraback/xxxxx/sys/dbsys_snap_YYYYMMDDHHMSS/audit
dir2:/oraback/xxxxx/sys/dbsys_snap_YYYYMMDDHHMSS

[ADDITIONAL INFORMATION]
- The nfs mount option are following:
rw,fg,hard,nointr,rsize=32768,wsize=32768,tcp,nfsvers=3,nolock
- This copy has usually done by using shell script.
The following are part of shell script:
CP=/bin/cp
　 COPY_FROM=/oradata/xxxxx/sys/.snapshot
　 COPY_TO=/oraback/xxxxx/sys
.........
rm -rf ${COPY_TO}/*
　 ${CP} -rp ${COPY_FROM}/* ${COPY_TO}

[FREQUENCY]
This phenomenon has occurred one time before now.

[QUESTION]
- Why does the message appear ?
Could you tell me the possibility of this message ?
- If we can not find root cause, we must make any advice to catch the root cause.
What shall we do to specify the root cause ?

Thank you for advice.
Best Regards.
/Minoru.Asano

[g33k]

cp whitout parametrs is used to copy files NOT directories...
cp -r dir1 dir2 should be OK

[g33k]

Sorry didn't read carefully.. I think problem is in links

Direct (hard) and indirect (soft or symbolic) links from one file or directory to another can be created using the ln command.




$ ln filename linkname




creates another directory entry for filename called linkname (i.e. linkname is a hard link). Both directory entries appear identical (and both now have a link count of 2). If either filename or linkname is modified, the change will be reflected in the other file (since they are in fact just two different directory entries pointing to the same file).




$ ln -s filename linkname




creates a shortcut called linkname (i.e. linkname is a soft link). The shortcut appears as an entry with a special type ('l'):




$ ln -s hello.txt bye.txt


$ ls -l bye.txt


lrwxrwxrwx 1 will finance 13 bye.txt -> hello.txt


$




The link count of the source file remains unaffected. Notice that the permission bits on a symbolic link are not used (always appearing as rwxrwxrwx). Instead the permissions on the link are determined by the permissions on the target (hello.txt in this case).




Note that you can create a symbolic link to a file that doesn't exist, but not a hard link. Another difference between the two is that you can create symbolic links across different physical disk devices or partitions, but hard links are restricted to the same disk partition. Finally, most current UNIX implementations do not allow hard links to point to directories.

So I guess you have some hard link in directory you are trying to copy.
Use ls -l to see if I'm right

[Minoru Asano]

Hello,

Thank you for quick reply.

I am trying to reproduce this phenomenon at my lab, but I could not it.
If possible, could you tell me how to reproduce this message ?

Thank you for advice.
Best Regards.
/Minoru.Asano

[g33k]

OK for human being:

check the directory you are trying to copy:

ls -l

if you will see something like that
lrwxrwxrwx 1 will finance 13 bye.txt -> hello.txt

it that it's not file but just link(ponter which refers to some real file).

the problem is that cp is not able to copy this hard link to another physical disk.

[Mike Stroyan · Accepted solution]

The error message is complaining that the two directories

/oraback/xxxxx/sys/dbsys_snap_YYYYMMDDHHMSS/audit
and
/oraback/xxxxx/sys/dbsys_snap_YYYYMMDDHHMSS

have the same inode number. They are two hard links to one directory. That is not supposed to happen. The cp source code has a comment noting that it does happen sometimes in Netapp servers.

/* Avoid damaging the destination file system by refusing to preserve
hard-linked directories (which are found at least in Netapp snapshot
directories). */

You could confirm the situation by running
ls -id /oraback/xxxxx/sys/dbsys_snap_YYYYMMDDHHMSS/audit
and
ls -id /oraback/xxxxx/sys/dbsys_snap_YYYYMMDDHHMSS

then observing that the two directories have the same inode number.

[Minoru Asano]

Hello,
Thank you for reply and detailed information.

>You could confirm the situation by running
>ls -id /oraback/xxxxx/sys/dbsys_snap_YYYYMMDDHHMSS/audit
>and
>ls -id /oraback/xxxxx/sys/dbsys_snap_YYYYMMDDHHMSS
>
>then observing that the two directories have the same inode number.

Unfortunately, those file was deleted by daily operation, so he could not
confirm the inode information.
He will confirm it at next trouble time.


By the way, he worry that the cp command argument which is specified at shell script was
different from error messages.
Regarding this phenomenon, is there any hints ?

He executed the cp command like following:
/bin/cp -rp SOURCE/.snapshot/dbsnap_sys_YYYYMMDDHHMISS/* DESTINATION/


The file except directory was copied successfully, so shell parameter or " * " seems be no problem.

After passing cp command's argument to /bin/ksh, is there any possibility to convert the path argument ?

Thank you for support and advice.
Best Regards.
/Minoru.Asano

[Mike Stroyan]

Your initial post indicated that the error message came from a script that did-
CP=/bin/cp
COPY_FROM=/oradata/xxxxx/sys/.snapshot
COPY_TO=/oraback/xxxxx/sys
.........
rm -rf ${COPY_TO}/*
${CP} -rp ${COPY_FROM}/* ${COPY_TO}

That matches the paths in the error output.
It would be copying both the directories that appeared in the error message.

If the command was-
/bin/cp -rp SOURCE/.snapshot/dbsnap_sys_YYYYMMDDHHMISS/* DESTINATION/

then something is not as it seems.
Perhaps you really meant $SOURCE and $DESTINATION, or some expansion of those parts of the paths. I would also be surprised that cp would mention that the
dbsnap_sys_YYYYMMDDHHMISS directory had the same inode as the dbsnap_sys_YYYYMMDDHHMISS/audit directory because that command line did not actually ask cp to copy the dbsnap_sys_YYYYMMDDHHMISS directory itself.