[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug in mv from fileutils 4.x when renaming symlink
From: |
Jim Meyering |
Subject: |
Re: Bug in mv from fileutils 4.x when renaming symlink |
Date: |
23 Nov 2000 15:56:33 +0100 |
User-agent: |
Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 |
Thanks for the reports.
Igor Bukanov <address@hidden> wrote:
| When I use mv to rename sym link to directory via:
|
| mv sym_link/ new_name
|
| mv actually rename the directory link point to. In some situation I also got:
That is known behavior -- it's not expected to change. See below.
Lobby the maintainer/author of your favorite shell to change
it so that it automatically removes such trailing slashes.
In the mean time, you can use mv's new --strip-trailing-slashes option.
| mv: basename.c:67: base_name: Assertion `all_slashes || *(p - 1) != '/'
failed.
|
| He is a simple test to reproduce the problem:
|
| cd /tmp
| mkdir test_dir
| touch test_dir/a
| ln -s test_dir link1
| mv link1/ link2
|
| This will rename test to link2 and left link1 as if.
That bug is fixed in the latest test release
ftp://alpha.gnu.org/gnu/fetish/fileutils-4.0.32.tar.gz
Here's the section in the latest manual that explains the
new --remove-trailing-slashes option:
Trailing slashes
================
Some GNU programs (at least `cp', `install', `ln', and `mv') allow
you to remove any trailing slashes from each SOURCE argument before
operating on it. The `--remove-trailing-slashes' option enables this
behavior.
This is useful when a SOURCE argument may have a trailing slash and
specify a symbolic link to a directory. This scenario is in fact rather
common because some shells can automatically append a trailing slash
when performing file name completion on such symbolic links. Without
this option, `mv', for example, (via the system's rename function) must
interpret a trailing slash as a request to dereference the symbolic link
and so must rename the indirectly referenced _directory_ and not the
symbolic link. Although it may seem surprising that such behavior be
the default, it is required by POSIX.2 and is consistent with other
parts of that standard.