Library - Fix build on MinGW32

[KoltesDigital]

Checklist

• [X] My code follows the style guidelines of this project
• [X] I have performed a self-review of my own code
• [X] I have commented my code, particularly in hard-to-understand areas
• [ ] I have made corresponding changes to the existing documentation
• [X] My changes generate no new warnings
• [ ] I have updated the change log (Add/Change/Fix)
• [X] I have cleaned up the commit history (use rebase and squash)

Changes proposed in this pull request:

Still upgrading the Rust bindings to 2.0.5...

Compilation on MinGW32 produces these errors:

  src/dokany/dokan\fileinfo.c: In function 'DokanEndDispatchFindStreams':
  src/dokany/dokan\dokani.h:197:34: warning: implicit declaration of function 'offsetof' [-Wimplicit-function-declaration]
    197 |   ((ioEvent)->EventResultSize >= offsetof(EVENT_INFORMATION, Buffer)           \
        |                                  ^~~~~~~~
  src/dokany/dokan\dokani.h:197:34: note: in definition of macro 'IOEVENT_RESULT_BUFFER_SIZE'
    197 |   ((ioEvent)->EventResultSize >= offsetof(EVENT_INFORMATION, Buffer)           \
        |                                  ^~~~~~~~
  src/dokany/dokan\fileinfo.c:29:1: note: 'offsetof' is defined in header '<stddef.h>'; did you forget to '#include <stddef.h>'?
     28 | #include <assert.h>
    +++ |+#include <stddef.h>
     29 | 
  src/dokany/dokan\dokani.h:197:43: error: expected expression before 'EVENT_INFORMATION'
    197 |   ((ioEvent)->EventResultSize >= offsetof(EVENT_INFORMATION, Buffer)           \
        |                                           ^~~~~~~~~~~~~~~~~
  src/dokany/dokan\dokani.h:197:43: note: in definition of macro 'IOEVENT_RESULT_BUFFER_SIZE'
    197 |   ((ioEvent)->EventResultSize >= offsetof(EVENT_INFORMATION, Buffer)           \
        |                                           ^~~~~~~~~~~~~~~~~
  src/dokany/dokan\dokani.h:198:48: error: expected expression before 'EVENT_INFORMATION'
    198 |        ? (ioEvent)->EventResultSize - offsetof(EVENT_INFORMATION, Buffer)      \
        |                                                ^~~~~~~~~~~~~~~~~
  src/dokany/dokan\dokani.h:198:48: note: in definition of macro 'IOEVENT_RESULT_BUFFER_SIZE'
    198 |        ? (ioEvent)->EventResultSize - offsetof(EVENT_INFORMATION, Buffer)      \
        |      

I just made what I was told!

[Liryna]

Hi @KoltesDigital, looks to be safe and not breaking other build environment so ✔️ Thanks for the fix and for your work in rust!

[KoltesDigital]

Thanks! Another step forward 🙂

Dokany's CICD only builds on MSVC, whereas the Rust lib also builds on MinGW 64 and 32. Do you think it'd be worth to add these targets to Dokany? This may be beneficial to other languages.

[Liryna]

What are the reasons your rebuilding the library ? Dynamically loading the MSVC library is not enough?

[KoltesDigital]

I've inherited the Rust CICD, and that was in there. See here for all build combinations. On one hand it's already there so let's keep it, on the other hand it's unexpectedly taking me quite some time to adapt to Dokan 2 and we can imagine it will be a burden in the future as well.

Besides, on MSVC, on rare occurrences, tests fail for unknown reason. For instance, FindFirstStreamW might return INVALID_HANDLE_VALUE, or SetFileTime might return FALSE. I suspect bad timings, even if test payloads are executed after DokanCreateFileSystem succeeded and the file system handler's mount has been called. I'll add a call to GetLastError in the assert message to have more clues. In the meantime, have you already encountered this behavior?

[Liryna]

I've inherited the Rust CICD

I can understand! If later this might change, I would suggest to just have the release zip downloaded and use the headers and binaries.

or instance, FindFirstStreamW might return INVALID_HANDLE_VALUE, or SetFileTime might return FALSE

Are you capable of reproducing it locally or is it only on the CICD ? If it is local, Procmon could be very helpful to find out when and why this happens. Or try to enable console debug log.

[KoltesDigital]

This occurred only on very few runs, only on the CICD. Good idea, I've enabled debug logs on the CICD. Latest runs succeeded, but hopefully we'll soon catch these gravitational waves.