Re: side-effect implementing the mv command

[Eric Blake]

[please keep replies on the list, so that others may chime in]

According to Derick Centeno on 3/2/2010 5:50 PM:
>> I'm not quite sure what you saw or what you are asking.  If this is still
>> an issue for you, could you post more context, such as some 'ls -l *.so'
>> listings in both the source and destination directories?  Also, are the
>> two directories on the same disk, where rename(2) would work, or was it a
>> cross-device move, where mv(1) has to create the copy before deleting the
>> original?
>>
> 
> Thanks for your response on this query, Eric.
> 
> Background:
> I had downloaded a java plugin designed for PowerPC systems, as I'm running
> Linux on a PowerPC.  That plugin is known as:  libjavaplugin_oji.so
> Originally it was installed into: /opt/ibm/java-ppc-60/jre/plugin/ppc/ns7
> 
> It is supposed to be moved into: /usr/lib/mozilla/plugins
> 
> When I executed the mv command from within the ns7 directory by doing:
> $ sudo mv ./libjavaplugin_oji.so /usr/lib/mozilla/plugins

Maybe the issue is related to the fact that you were trying to move a
symlink, rather than an actual file?  If the symlink contains a relative
filename, the moved symlink will contain the same relative name, but by
virtue of the fact that it lives in a different directory, it will (most
likely) resolve to something different than what it referred to in the
original location.

> 
> Eric, it was only after I studied the man/info pages more carefully regarding
> how mv should be executed (and other references) and how it should behave that
> I checked the directory where it was and where I expected it to go.
> 
> Here it is in the ns7 directory:
> 
> address@hidden ns7]$ ls
> libjavaplugin_oji.so
> 
> Here is what the plugins directory looks like:
> 
> address@hidden plugins]$ ls
> libgnashplugin.la  libgnashplugin.lai  libgnashplugin.so  libjavaplugin_oji.so

I asked for 'ls -l' so we could see full details, such as which files are
symlinks.  According to your screenshot, you happen to have plain 'ls'
aliased to a coloring version; with the four files on that line colored
red, black, green, and blue (I'm guessing dangling symlink, regular file,
symlink, executable); but rather than having to decode your colors, an 'ls
-l' would have shown that unambiguously in black and white.

> 
> Please note that it is very clearly indicated on my system that within the
> plugins directory libjavaplugin_oji.so is a link.  I believe it is linking 
> back
> to the file in the ns7 directory which is a bone fide shared object file.  

Indeed, moving relative symlinks can have some surprising effects, if you
aren't expecting them.  But there is no bug; this is how POSIX specifies
mv(1) behavior on symlinks.

> What I'm writing to you about is that due to the unusual way I executed the mv
> command what occured was not a clean standard execution of mv, but a side
> effect where a link was created back to the shared object file.

I'm not sure why you think there was a side effect.  If the source file
was a symlink to the shared object file, then after the move, the
destination will also be a symlink; whether the new link is dangling is a
matter of its contents in relation to its new location.  That's normal
behavior, not a side effect.

> By the way, just so there is clarity about this I'm forwarding to you a
> snapshot of an open terminal on my desktop displaying the color coding
> active within the terminal for your review.  The terminal color code sequence
> is fairly standard and should help verify what I'm reporting.

It's better to copy and paste contents of the terminal than it is to send
screenshots of text data (much less bandwidth).  In this case, sending the
screenshot happened to let me fill in some gaps, but I'm not going to
forward the screenshot on to the list.

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature