Attempting to run a command to the effect of 'ln -s Dir /path/to/DestDir/Dir creates a broken symlink to "Dir" in /path/to/DestDir/. See the attached script for automated bug reproduction. Same effect also happens when using the '-T' option. Reproducible: Always Steps to Reproduce: (see the script) Actual Results: A symbolic link to 'Dir' is created in /path/to/DestDir Expected Results: A symbolic link to "$(pwd)/Dir" is created in /path/to/DestDir Portage 2.1.4 (default-linux/x86/2007.0/desktop, gcc-4.2.2, glibc-2.7-r1, 2.6.23-gentoo-r6 i686) ================================================================= System uname: 2.6.23-gentoo-r6 i686 Genuine Intel(R) CPU T2050 @ 1.60GHz Timestamp of tree: Sun, 20 Jan 2008 21:16:01 +0000 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.4 [enabled] app-shells/bash: 3.2_p33 dev-java/java-config: 1.3.7, 2.1.3 dev-lang/python: 2.4.4-r5, 2.5.1-r5 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="x86 ~x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -mtune=i686 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -mtune=i686 -pipe" DISTDIR="/srv/gentoo/distfiles" EMERGE_DEFAULT_OPTS="" FEATURES="buildpkg ccache distcc distlocks getbinpkg metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://lishkalishkaw/gentoo/ http://gentoo.osuosl.org/ ftp://distro.ibiblio.org/pub/linux/distributions/gentoo/" LANG="en_US.ISO-8859-1" LC_ALL="en_US.ISO-8859-1" MAKEOPTS="--quiet -j7" PKGDIR="/srv/gentoo/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="X a52 aac aalib acl acpi adns alsa apache2 arts bash-completion bcmath berkdb bindist bitmap-fonts bzip2 cairo caps cddp cdr cjk clamav cli cracklib crypt cscope ctype cups curl curlwrappers dbase dbm dbus dga directfb dri dts dvd dvdr dvdread eds emacs emboss encode evo examples exif expat fam fastcgi fbcron ffmpeg fftw firefox flac foomaticdb fortran freetds ftp gd gdbm geoip ggi gif glut gmp gnustep gnutls gpm graphviz gstreamer gtk gtkhtml hal howl icc iconv icq idn imagemagick imap imlib informix innodb ipod ipv6 isdnlog jabber jack java javascript jbig joystick jpeg jpeg2k junit kde kdexdeltas kerberos krb4 ladspa lapack lcms ldap leim lesstif libcaca libg++ libnotify libsamplerate libwww lirc lm_sensors mad maildir matroska matrox mbox mcal midi mikmod mime mmx mono mp3 mpeg mpi mplayer mpm-threadpool msn mudflap mule musepack musicbrainz mysql mysqli nas ncurses nls nntp nocd nptl nptlonly offensive ofx ogg openexr opengl openmp osc oscar oss pam pcntl pcre pdf perl php plotutils png postfix ppds pppd profile python qt3 qt3support qt4 quicktime rdesktop readline reflection sdl session sharedext shorten smp snmp soap sockets source speex spell spl sse sse2 ssl startup-notification svg svga symlink sysvipc tcpd tetex theora threads tidy tiff tokenizer truetype truetype-fonts type1-fonts unicode usb vcd vhosts videos vorbis win32codecs x86 xcomposite xface xine xml xorg xosd xpm xprint xscreensaver xsl xulrunner xv xvid yahoo zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" APACHE2_MPMS="worker" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="apm ark chips cirrus cyrix dummy fbdev glint i128 i740 i810 imstt mach64 mga neomagic nsc nv r128 radeon rendition s3 s3virge savage siliconmotion sis sisusb tdfx tga trident tseng v4l vesa vga via vmware voodoo" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Created attachment 141504 [details] Script automatically exposes the bug in question
Kindly read man ln *before* filing bugs...
(In reply to comment #2) > Kindly read man ln *before* filing bugs... > I did. This is what it reads: `ln' makes links between files. By default, it makes hard links; with the `-s' option, it makes symbolic (or "soft") links. Synopses: ln [OPTION]... [-T] TARGET LINKNAME ln [OPTION]... TARGET ln [OPTION]... TARGET... DIRECTORY ln [OPTION]... -t DIRECTORY TARGET... * If two file names are given, `ln' creates a link to the first file from the second. ... So according to the manual, the behavior of ln creating BROKEN symlinks to a file is a BUG. Please reopen this bug.
Yeah, except that you got the arguments the other way round... If you have more questions, see http://www.gentoo.org/main/en/support.xml, thanks.
No, I have the order of the operators right. I am trying to create a symbolic link to ./Dir that IS CREATED IN ./path/to/DestDir/, not the other way around. BTW, reversing the operators creates a broken symbolic link to ./path/to/DestDir/ in ./Dir/ So unless you have a better argument (with info manual citations to back it up), this is a legitimate bug and deserves to be reopened.
(In reply to comment #5) > No, I have the order of the operators right. No, you don't. > I am trying to create a symbolic link to ./Dir that IS CREATED IN > ./path/to/DestDir/, not the other way around. Yeah, so use `ln -s /path/to/DestDir/Dir Dir` as the manpage told you - which will create a symlink named "Dir" in $PWD which is pointing to "/path/to/DestDir/Dir" (and move this out from bugzilla already). Thanks.
(In reply to comment #6) > (In reply to comment #5) > > No, I have the order of the operators right. > > No, you don't. > > > I am trying to create a symbolic link to ./Dir that IS CREATED IN > > ./path/to/DestDir/, not the other way around. > > Yeah, so use `ln -s /path/to/DestDir/Dir Dir` as the manpage told you - which > will create a symlink named "Dir" in $PWD which is pointing to > "/path/to/DestDir/Dir" (and move this out from bugzilla already). > > Thanks. > I can see we're just not going to see eye-to-eye on this issue, so why don't we get a third party involved in this and see what they think. OK?
This is not neither an arbitration forum, not a support forum. Bugzilla is here for bugs. Your ln usage is clearly incorrect. Once again and for the last time - please take this out from bugzilla This bug is closed and nothing new will happen here.
(In reply to comment #7) > I can see we're just not going to see eye-to-eye on this issue, so why don't > we get a third party involved in this and see what they think. OK? I am a third party and you are wrong.
(In reply to comment #9) > (In reply to comment #7) > > I can see we're just not going to see eye-to-eye on this issue, so why don't > we get a third party involved in this and see what they think. OK? > > I am a third party and you are wrong. > Ok, where EXACTLY am I wrong? Sofar, I've gotten little more than hubris for arguments and it's really annoying me. To facilitate this discusion, let's take a page out of the info page for ln: 12.2 `ln': Make links between files =================================== `ln' makes links between files. By default, it makes hard links; with the `-s' option, it makes symbolic (or "soft") links. Synopses: ln [OPTION]... [-T] TARGET LINKNAME ln [OPTION]... TARGET ln [OPTION]... TARGET... DIRECTORY ln [OPTION]... -t DIRECTORY TARGET... * If two file names are given, `ln' creates a link to the first file from the second. * If one TARGET is given, `ln' creates a link to that file in the current directory. * If the `--target-directory' (`-t') option is given, or failing that if the last file is a directory and the `--no-target-directory' (`-T') option is not given, `ln' creates a link to each TARGET file in the specified directory, using the TARGETs' names. .... Bad Example: # Hard coded file names don't move well. ln -s $(pwd)/a /some/dir/ Better Example: # Relative file names survive directory moves and also # work across networked file systems. ln -s afile anotherfile ln -s ../adir/afile yetanotherfile So now that we've got some stuff to work with, I would like to point out that in the first bullet of ln's info page that it says quite clearly that creates a link to the first file from the second. Now if a link is to be created to the first file from the second, how can such a link be made if ln takes in literally the TARGET argument and doesn't process the argument such that either an absolute path is given for the TARGET using the directory or (better, and going along with the apparent preferred uses of ln by GNU) adding a set of relative paths to the TARGET such that the TARGET can be properly reached from the LINKNAME? So as I see it, there are two possibilities for ln's current behavior: 1) There is a BUG in ln's logic for creating symbolic links to a TARGET. or 2) There is a BUG in ln's man and info pages. Either way, this bug is not invalid for the reasons given above. Now, if you still don't believe me, either PROVE that I'm wrong using evidence and direct citations from the manuals or reopen this bug.
Restricting this bug to prevent more noise... Since you have been asked multiple times to cease commenting here, any further abuse of bugzilla will result in suspension of your account, thanks for understanding.
