Please do not reply to this email- if you want to comment on the bug, go to the URL shown below and enter your comments there.
Changed by [EMAIL PROTECTED] http://bugzilla.ximian.com/show_bug.cgi?id=79887 --- shadow/79887 2006-11-10 13:34:07.000000000 -0500 +++ shadow/79887.tmp.12733 2006-11-11 07:51:14.000000000 -0500 @@ -45,6 +45,25 @@ for how ms plans to deal with symbolic links in future releases. Not all the mono io-layer code handles symlinks correctly according to that link, but the DirectoryInfo change is correct in its current behaviour. A simple C test on windows also shows GetFileAttributes() called on a symlink to a directory returns info on the symlink. + +------- Additional Comments From [EMAIL PROTECTED] 2006-11-11 07:51 ------- +Ok, I agree with you, but you pointed me to the wrong bugreport regard +the regression if using Directory.Exists() on symlinks that points to +directories, that is different than getting the DirectoryInfo like in +this bugreport was stated. + +Directory.Exists() breaks many code, for example it breaks the +compiler, you can _not_ compile anything anything if the sources comes +from a symlinked path or if the compile target goes to a symlinked +path. This is a big problem. + +About the Microsoft link, to me it looks like they do the almost same +as Unix does for the file operations. + +So what is the cause of this bug then? I only could find +Directory.Exists as cause via mono --trace which returns False because +my source files are "behind" a symlinked directory. + _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
