From: Eric K. <ek...@rz...> - 2002-06-27 10:53:06
|
"Casper Hornstrup" <ch...@us...> wrote: > I was confused about the messages about the modules not beeing found. Maybe we should > change this message to something like "<module> not found. Trying to load...". What about "<module> not loaded yet. Loading...". > Actually the failure to open the symbolic link was non-critical. I think the OBJ_OPENLINK flag is missing so it should be: > > --- symlink.orig Thu Jun 27 02:20:04 2002 > +++ symlink.c Thu Jun 27 01:22:24 2002 > @@ -192,6 +192,8 @@ > DPRINT("NtOpenSymbolicLinkObject (Name %wZ)\n", > ObjectAttributes->ObjectName); > > + ObjectAttributes->Attributes |= OBJ_OPENLINK; > + > return(ObOpenObjectByName(ObjectAttributes, > IoSymbolicLinkType, > NULL, > > --- arcname.orig Thu Jun 27 02:19:14 2002 > +++ arcname.c Thu Jun 27 01:36:29 2002 > @@ -291,7 +291,7 @@ > /* Check whether '\SystemRoot'(LinkName) can be opened */ > InitializeObjectAttributes(&ObjectAttributes, > &LinkName, > - 0, > + OBJ_OPENLINK, > NULL, > NULL); > > > But, with the following patch, NtOpenSymbolicLinkObject() makes more > sense to me. Comments? No! If the OBJ_OPENLINK attribute is set, a link object will be opened instead of the target it points to. So you have to use OBJ_OPENLINK if you want to retrieve link's target path, change a link's target path or delete a link object but not the object it points to. But if you want to open the target of a link OBJ_OPENLINK must not be set. In the current case NtOpenSymbolicLink() is used to check whether \SystemRoot points to an existing target by trying to open the target. Opening the link object instead will cause the call to succeed even if the link's target does not exist or cannot be opened for some other reason. > The real problem was with the new MinGW runtime (1.5). There are several issues related > issues related to this. If we make a release now, we should make a note > in the release notes that MinGW runtime 1.5 currently cannot be used to > compile ReactOS. Ooops! Eric |