This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Native symbolic links to non-existent targets (possible bug?)

Cygwin appears to ignore "winsymlinks:native" when asked to create a symbolic link to a non-existent target, reverting to its "magic header" approach.

This can be demonstrated via the following examples (using a Cygwin shell):
  echo hello > aaa
  ln -s aaa bbb
  notepad bbb

  ln -s xxx yyy
  notepad yyy

"notepad bbb" will show "hello", but "notepad yyy" produces "ãçææ ãïxxx ". "bbb" is a native symbolic link, "yyy" is not. (This can also be confirmed using "dir" (cmd.exe /c dir from within Cygwin) or looking for the curved arrow glyph in the folder explorer.)

Note that this is in contrast to mklink (using a command prompt):
  echo hello > aaaa
  mklink bbbb aaaa
  notepad bbbb

  mklink yyyy xxxx
  notepad yyyy

In this case, both mklink commands succeed; "notepad bbbb" works as expected, and "notepad yyyy" pops up an alert with "Cannot find the yyyy file. Do you want to create a new file?", which makes sense (it even writes to xxxx if you say "yes").

Also, mklink-created symbolic links to non-existent targets appear to work (just as they do on *nix) when the non-existent target is created:
  echo hello again > xxxx
  notepad yyyy

The result is now "hello again".

I initially stumbled upon this discrepancy in the following real-world example:
  git init foo
  cd foo
  touch .gitignore
  git add .gitignore
  git commit -m 'first commit'
  git checkout -b links
  mkdir -p a/b
  echo hello > a/file_in_a
  ln -s ../file_in_a a/b/link_to_file_in_a
  git add a
  git commit -m 'Added symbolic link'

At this point, we have a valid, native symbolic link, which can be confirmed using notepad as before:
  notepad a/b/link_to_file_in_a

We run into problems, however, when we do the following:
  git checkout master && git checkout links

Git will create the symbolic link *before* it creates the target, and the result is a non-native file. "notepad a/b/link_to_file_in_a" now produces "ãçææãï../file_in_a ".

Shouldn't Cygwin honor "winsymlinks:native" even with the target does not exist?

I'm using Cygwin 6.1.

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]