Hello everyone, I haven't checked for any impacted software, but I suspect this issue would stop other network connected server software from operating. It is not an uncommon method to use in Linux based multi threaded server software. After tracing the failure carefully I developed some test code t...

Hello again, I think I have traced one part of the problem to a problem with the Winsock implementation in ReactOS. It is another slightly unusual problem, so I wanted to ask about it before posting it on Jira. The issue appears to be in the implementation of the connect() function. I will include c...

Hello again, I made some progress with getting Samba working, but it seems that datagram communications will not work on ReactOS. I am working on tracing the details, but so far it seems to be related to two things. The first is that several Winsock IOCTL calls are not present in ReactOS yet. One of...

victor6799, Looking through the code is the only way to see the details, but as I said before I believe there are actually several ways this happens. In a running system each thread returns control to the kernel when it finishes a task via yield or exit, since there are multiple threads in virtually...

I think it's likely that a thread scheduling check also takes place when there are interrupts (IRQs or interrupt requests IRPs) being processed because handling them often requires a context switch. I haven't seen that in the source, but suspect it's there somewhere. Hardware generated Interrupts ar...

I'm not a dev either, but it's an interesting question. Look at KE/thrdschd.c for a bit more information. I'll try to answer you with a sort of paraphrased high level summary of sorts based on what I have seen so far. Anyone out there that wants to correct my mistakes is invited to do so because I a...

That is true, but neither Cygwin or the test applications fail under windows when they make the same calls, so internally Windows handles this case very differently than ReactOS currently does. Thank you for your help, the test that you sent makes it possible to recreate the error using ROSBE based ...

learn_more, The reason your test code does not fail is that you re-used the same structures for both calls to NtOpenFile, while in my Delphi test app I declared two independent structures for ObjectAttributes, iosb, and FileStandardInformation. It seems that if a string is already present in the str...

Didn't mean to annoy you. I am working on building the test you sent to see if I can reproduce the failure with it. I did extract some code out of Cygwin that shows the pattern used in the code, but I'll hold onto that until I can reproduce the failure with the test.

bigdude

That test failing on ROS would essentially confirm that a bug exists in ROS in the API call NtOpenFile(). How should it be formally reported if confirmed ? There must be something lost if your test worked in ROS. The only obvious difference between the pseudocode and my test in Delphi would be the p...

Learn_more, You are correct, that was a typo in the pseudocode (which I'll fix momentarily). The Delphi test app did not have that error in it. I have been looking through more of the Cygwin code and they actually use this method pretty heavily in their code and refer to it as a 'reopen' of a file. ...

I actually did write a test for this, but since I do not really do much programming in C I did it under a tool I'm more familiar with which was Delphi. The test binary produced different results under Win10 than ROS, but in the end it showed that was not an issue with validation. The returned error ...

Cygwin directly calls NtOpenFile() in both cases, it targets the internal API for most of its calls rather than the main winapi. I looked on MSDN and did not find anything in the MS Docs that indicates that making a call to NtOpenFile in this fashion is incorrect or invalid, or that precludes leavin...

I wonder if someone could help me build a small workaround for this problem. Basically what happens is this.. The library(cygwin) calls NtOpenFile using a path and the call works completely and the application gets back a File Handle. The library then it tries to reopen that same file by calling NtO...

That sounds very interesting and potentially a big move for ReactOS. I am still tinkering with this because it looks like there may be small issues in the object manager as well (for this oddball edge case usage anyway). I don't know why it doesn't happen on BtrFs, but the traces look like ObOjectLo...