On 4/5/2011 9:21 AM, Arnaud Charlet wrote: >> I'm one of the MSys "devs" (if you want to call the sporadic process of >> updating MSys "development"). I'll take a look at implementing >> ln -s file dir >> as synonymous with >> ln -s file dir/basename-of-file >> in the next few days. > > Thanks, although the case we're really interested in here is: > > cp -p file dir > as equivalent to > cp -p file dir/basename-of-file
Well, THAT already works on MSYS: $ echo "test data" > foo $ mkdir bar $ cp -p foo bar $ ls bar foo The problem with ln -s is this: CYGWIN: $ echo "test data" > foo $ mkdir bar $ ln -s foo bar $ ls -l bar total 1.0K lrwxrwxrwx 1 owner group 3 Apr 5 09:57 foo -> foo Note that this link, on cygwin, is broken anyway (and circular) but it DOES succeed. You get the same behavior on linux. MSYS: $ echo "test data" > foo $ mkdir bar $ ln -s foo bar ln: creating symbolic link `bar/foo' to `foo': No such file or directory This happens because MSYS's 'ln -s' (i.e. symlink(2)) can't resolve the relative path "foo" from within the "bar" directory, so it can't figure out how to 'fake' the symlink (MSYS always does fake symlinks, using copy). Basically, this is a symptom of a larger issue: because MSYS fakes symlinks using copy, there is no such thing as a "dangling symlink" on MSYS -- and any attempt to create one will fail. What I'm talking about is special casing this particular usage, so that on MSYS: $ ln -s file dir acts like $ cp -p file dir Note that even on linux, if you wanted a non-dangling symlink, you'd need to express the ln -s command as $ ln -s ../file dir because the path-to-target, if relative, needs to be relative from the location of the symlink, not from the cwd. So...is this still an issue with MSYS, or is it a bug in Ada's build procedure that it deliberately tries to create a dangling symlink? -- Chuck
