LinuxQuestions.org - unexpected behaviour of cp (ext3?)

- Linux - Software (https://www.linuxquestions.org/questions/linux-software-2/)

- - unexpected behaviour of cp (ext3?) (https://www.linuxquestions.org/questions/linux-software-2/unexpected-behaviour-of-cp-ext3-703884/)

unexpected behaviour of cp (ext3?)

Code:

cp api.odt ../../../unified

I did a copy of an odt to a directory and when I checked that folder, the file was not there. The copy command was done from the doc directory

I went back there and saw if I messed up something when I gave the path. But everything was correct. Then happened this bizarre stuff.

Code:

[root@DER01C doc]# file ../../../unified 

../../../unified: OpenDocument Text

[root@DER01C doc]# cd ../../../unified 

[root@DER01C unified]# pwd

/work/unified

[root@DER01C unified]# ls

comctl  dll.txt  docs  mnt  mnt.tbz  monodevelop-124664-0.novell.noarch.rpm

Recently I was noticing that when I press tab for file name completion, a / was appearing at the end of file name (File was not a folder). I ignored it at that time. But now I think these two may be related. Any explanations?

This is seen on a Fedora 7 machine.

Code:

[root@DER01C work]# uname -a

Linux DER01C 2.6.23.17-88.fc7 #1 SMP Thu May 15 00:35:10 EDT 2008 i686 i686 i386 GNU/Linux

Quite likely your path '../../../unified' refers to a symbolic link in the filesystem. In this case, the '..' will reference the actual directories, and not the path along the links. You aren't the first to have been bitten by this. To demonstrate what I mean, try the following (this is most revealing if you have a bash prompt using something like 'PS1=[\u@\h \w]':

Code:

mkdir -p /tmp/dir1/dir2/dir3/dir4

mkdir -p /tmp/dirA/dirB/dirC

cd /tmp/dirA/dirB/dirC/

ln -s /tmp/dir1/dir2/dir3/dir4 .

cd dir4

# Prompt displays '[usename@host /tmp/dirA/dirB/dirC/dir4]'

ls ../../..

# One expects to see 'dirA', but....

echo "hello world" > ../../../helloworld.txt

# Similarly, one might expect this to have created '/tmp/dirA/helloworld.txt', but again...

cd ../../..

# To be consistent, by now you would expect $PWD to be '/tmp/dir1', like above, but another surprise!

pwd

Go figure.

--- rod.

Quote:

Originally Posted by theNbomr (Post 3439810)

Quite likely your path '../../../unified' refers to a symbolic link in the filesystem. In this case, the '..' will reference the actual directories, and not the path along the links.

Code:

[root@DER01C work]# ls -l unified

total 14296

drwxr-xr-x 3 root root    4096 2009-02-02 11:40 comctl

-rw-r--r-- 1 root root    930 2009-02-02 12:04 dll.txt

drwxr-xr-x 3 root root    4096 2009-02-11 00:44 docs

dr-xr-xr-x 3 root root    4096 2008-04-23 20:32 mnt

-rw-r--r-- 1 root root 9197484 2009-02-03 08:18 mnt.tbz

-rw-r--r-- 1 root root 5393680 2009-01-27 23:06 monodevelop-124664-0.novell.noarch.rpm

Thanks for the reply. But, clearly, that is not the case (See ls -l o/p. If it was a link, it should have shown where it points to.). Also, CWD for that command was also a proper directory. Note that I did the file and cd from the same location. That is, when I run file from with in the "doc" folder, "../../../unified" is recognized as an odt. But, I can "cd" to to the same path from "doc" directory. (There can only be one file *w.r.t. doc folder* that has a relative path "../../../unified". And this cannot be a file and directory at the same time). Any other explanation?

<edit>
After posting this, I did stat on "../../../unified" and then a stat on "/work/unified". They were in fact two different files (Had different inodes). Then I tried to recreate the problem and I suddenly noticed that one of the top directories of the "doc" directory was a link (I have reached doc cd /work/f1/f2/doc. f1 was a link). You were correct theNbomr. Thanks.
</edit>