primordic/IssueDupesLite huggingface dataset:
Repository: doctest/doctest

Issue #53: How can I mix production code with the Unit Tests?
Created: 2017-03-05T03:04:12Z
How can I mix production code with the Unit Tests?
Initial page says:

This allows the framework to be used in more ways than any other - tests can be written directly in the production code!



This makes the barrier for writing tests much lower - you don't have to: 1. make a separate source file 2. include a bunch of stuff in it 3. add it to the build system and 4. add it to source control - You can just write the tests for a class or a piece of functionality at the bottom of its source file - or even header file!
Tests in the production code can be thought of as documentation or up-to-date comments - showing how an API is used
Testing internals that are not exposed through the public API and headers becomes easier!


How can I mix production code with the Unit Tests?
I am thinking about just doing the #include "doctest.h", and writing the tests down, but how the Unit Tests code will not end up on the production binary after compiled from the main program, instead of the Unit Tests Driver Class:
#define DOCTEST_CONFIG_IMPLEMENT_WITH_MAIN
#include "doctest.h"
I found out this macro DOCTEST_CONFIG_DISABLE. Therefore how would it work, I would have to define it on every production source code file, to disable the Unit Tests?

Duplicate issue #8: Interaction with --gc-sections ?
Created: 2016-05-23T10:50:16Z
When compiling a testcase with -ffunction-sections and -fdata-sections, and linking with --gc-sections (or alternatively, -flto entirely), do the test cases get removed if there is no runner in the executable, or if it is not linked in?

Closing comment (2020-07-16T15:09:37Z): I tested this with just DOCTEST_CONFIG_IMPLEMENT and an empty main but the tests are still referenced due to the automatic registration.
Related to #53 (comment).
Repository: doctest/doctest

Issue #854: cmake: Warning/error because of low minimum required cmake version
Created: 2024-05-20T13:37:33Z
Description
Doctest CMakeLists.txt contains the following line:
cmake_minimum_required(VERSION 3.0)
When doctest is used in another CMake project as test framework, the following CMake warning is shown:
CMake Deprecation Warning at build/_deps/doctest-src/CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.

This warning can be removed by adapting the line using the solution below:
# -- SOLUTION NEEDS: CMAKE_MIN_VERSION >= 3.5
cmake_minimum_required(VERSION 3.5)
AFFECTED FILES IN REPOSITORY:

CMakeLists.txt
examples/installed_doctest_cmake/executable/CMakeLists.txt
examples/installed_doctest_cmake/dll/CMakeLists.txt
scripts/how_stuff_works/CMakeLists.txt

Steps to reproduce
$ pip install cmake 
$ cmake --version
cmake version 3.29.3

$ cmake -S . -B build
...
CMake Deprecation Warning at build/_deps/doctest-src/CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.
...
Extra information

doctest version: v2.4.11

Duplicate issue #893: Compatibility with CMake < 3.5 has been removed from CMake.
Created: 2025-02-13T20:55:43Z
CMake Error at /Users/clausklein/.cache/CPM/doctest/12db48f882577765012289eff316f2dbc7e50937/CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 has been removed from CMake.

  Update the VERSION argument <min> value.  Or, use the <min>...<max> syntax
  to tell CMake that the project requires at least <min> but has been updated
  to work with policies introduced by <max> or earlier.


-- Configuring incomplete, errors occurred!

Closing comment (2025-02-13T21:17:40Z): Duplicate #854 ?
Repository: doctest/doctest

Issue #192: std::array doesn't have a default printer.
Created: 2019-03-11T03:25:33Z
Hi.
For std::array comparison I get:
REQUIRE( {?} == {?} )
I believe you support this for other containers. Can you add this when/if you have the time?

Duplicate issue #248: Vector contents show up as question mark
Created: 2019-06-24T18:25:14Z
Description
I recently switched from the Catch2 library due to the improved compile times and everything seems to have gone flawlessly. However, I noticed that when comparing vector values fails, unlike Catch2 which will print the contents of the vectors, I just get this:
===============================================================================
test/test-encoding.cpp:73:
TEST CASE:  std::string to_utf16le_bytes(std::u16string)

test/test-encoding.cpp:79: FATAL ERROR: REQUIRE( result == expected ) is NOT correct!
  values: REQUIRE( {?} == {?} )

===============================================================================

whereas with Catch2 it provides the contents of the vectors:
test/test-encoding.cpp:90: FAILED:
  REQUIRE( result == expected )
with expansion:
  { '�', '2', '�', '2' }
  ==
  { '2', '�', '2', '�' }

===============================================================================

I know #170 matches this fairly exactly, but in that case he was dealing with templates and localization was the issue that was resolved, which I don't believe (off the top of my head) should apply in this situation. The contents of the vectors are uint8_t (unsigned char on most x64 systems), so I don't believe it has to do with the contents.
Steps to reproduce
Compile the following with doctest.h (g++ test.cpp doctest.h -o vector_test) and see result:
// Tell doctest library to create a main for this file - only include this line once!
#define DOCTEST_CONFIG_IMPLEMENT_WITH_MAIN

#include <vector>

#include "doctest.h"

using namespace std;

TEST_CASE("Compare vectors")
{
  vector<uint8_t> expected{ 0x32, 0xdb, 0x32, 0x8d };
  vector<uint8_t> result{ 0x32, 0x00, 0x32, 0x00 };

  REQUIRE(expected == result);
}
Result
[doctest] doctest version is "2.3.3"
[doctest] run with "--help" for options
===============================================================================
test/test-test.cpp:10:
TEST CASE:  Compare vectors

test/test-test.cpp:15: FATAL ERROR: REQUIRE( expected == result ) is NOT correct!
  values: REQUIRE( {?} == {?} )

===============================================================================
[doctest] test cases:      1 |      0 passed |      1 failed |      0 skipped
[doctest] assertions:      1 |      0 passed |      1 failed |
[doctest] Status: FAILURE!


doctest version: v2.3.3
Operating System: Ubuntu 19.04 on Linux 5.0.0-17-generic
Compiler+version: clang 8.0.0-3/g++ (Ubuntu 8.3.0-6ubuntu1) 8.3.0

Closing comment (2024-08-15T22:23:24Z): This is a duplicate of #192 .
Closing issue due to that and existing workaround.
Repository: doctest/doctest

Issue #854: cmake: Warning/error because of low minimum required cmake version
Created: 2024-05-20T13:37:33Z
Description
Doctest CMakeLists.txt contains the following line:
cmake_minimum_required(VERSION 3.0)
When doctest is used in another CMake project as test framework, the following CMake warning is shown:
CMake Deprecation Warning at build/_deps/doctest-src/CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.

This warning can be removed by adapting the line using the solution below:
# -- SOLUTION NEEDS: CMAKE_MIN_VERSION >= 3.5
cmake_minimum_required(VERSION 3.5)
AFFECTED FILES IN REPOSITORY:

CMakeLists.txt
examples/installed_doctest_cmake/executable/CMakeLists.txt
examples/installed_doctest_cmake/dll/CMakeLists.txt
scripts/how_stuff_works/CMakeLists.txt

Steps to reproduce
$ pip install cmake 
$ cmake --version
cmake version 3.29.3

$ cmake -S . -B build
...
CMake Deprecation Warning at build/_deps/doctest-src/CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.
...
Extra information

doctest version: v2.4.11

Duplicate issue #889: Benchmark script with no arguments
Created: 2025-02-01T01:50:26Z
Running without arguments errors with
$ python bench.py 
Traceback (most recent call last):
  File "/home/jx/projects/doctest/scripts/bench/bench.py", line 45, in <module>
    args.func(args)
AttributeError: 'Namespace' object has no attribute 'func'

Should have a friendlier message.
Also running every time has a CMake deprecation warning
CMake Deprecation Warning at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 2.8.12 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.

Closing comment (2025-02-01T02:16:51Z): CMake warning dupe #854
Repository: dokan-dev/dokany

Issue #413: After 1 hour of sleep mirror.exe stops unexpectedly
Created: 2016-12-22T15:01:27Z
Environment

Windows version: Windows 10 Pro x64 v1607 14393.576
Processor architecture: x64 Core i7-4650U
Dokany version: 1.0.1.1000 (tested both normal and dbg)
Library type (Dokany/FUSE): Dokany/mirror

Check List

 I checked my issue doesn't exist yet
 My issue is valid with mirror default sample and not specific to my user-mode driver implementation
 I can always reproduce the issue with the provided description below.
 I have updated Dokany to the latest version and have reboot my computer after.
 I tested one of the last snapshot from appveyor CI.

Description
On Surface Pro 3 after about 1 hour device sleep Mirror.exe stops unexpectedly and drive get unmounted.
mirror.exe runned as /r c:\ /l m /d
Actually first time noticed by one of users of my dokan.net based app also with some Surface device.
Have no other laptop to try.
Tried latest snapshot 1.0.1-50 3e2320e but it does not work at all.
dokanctl /v returns
Dokan version : 100
Dokan Error: Failed to open \\.\Dokan_1 with code 2
Dokan driver version : 0x0

Rebooted after uninstalling other dokany and rebooted after installing this one.
Logs
mirror.zip
Support

Usage: personal - production
Support ability:

Duplicate issue #554: Windows 10 build 16232 become unresponsive when using winsshfs/dokany
Created: 2017-07-12T14:09:34Z
Environment

Windows version: 10
Processor architecture: x64
Dokany version: 1.0.13
Library type (Dokany/FUSE): FUSE (I think).

Check List

 I checked my issue doesn't exist yet
 My issue is valid with mirror default sample and not specific to my user-mode driver implementation
 I can always reproduce the issue with the provided description below.
 I have updated Dokany to the latest version and have reboot my computer after.
 I tested one of the last snapshot from appveyor CI

Description
This is cross post of feo-cz/win-sshfs#152 as I'm unsure if the problem come from winsshfs or dokany.
The computer become unresponsive when mounting a remote filesystem using sshfs since windows 10 build 16232 . Application continue to run, and mouse still move on the screen, but it is impossible to interact with anything - click does nothing and typing on the keyboard does nothing.
I tried various version of dokany and got the same result, including the latest.
Everything works great with previous builds of windows 10. Currently download build 16237 to see if the problem persist there.
Logs
Computer become unresponsive when the problem occurs, so not sure how to proceed here.

Closing comment (2017-09-15T11:47:56Z): @Liryna Nope, seems not the same as #413 .
I'll try to do it clean in VM and make sure it can be reproduced by everyone.
I think it's mostly the same as the OP's, except that my mouse and keyboard are still working.
PS: actually it begines from Win 16251. On the previous normal release, aka Win 10 1607, I was using old winsshfs stable with dokan 0.7.4, flawlessly. However this combination will still cause freeze on 16251.
Repository: dokan-dev/dokany

Issue #187: Windows requires a digitally signed driver
Created: 2016-03-03T09:40:31Z
when installing "DokanSetup_redist.exe" in v1.0.0-RC1

I'm on Windows Enterprise 7

Duplicate issue #196: Doesn't work on Windows 7 Enterprise
Created: 2016-03-11T17:59:39Z
Feature request can skip this form. Bug report must complete it. Check List must be 100% match or it will be automatically closed without further discussion. Please remove this line.
Environment

Windows version: Windows 7 Enterprise
Processor architecture: core i7
Dokany version: 1.o RC2
Library type (Dokany/FUSE): Dokany

Check List

 I checked my issue doesn't exist yet
 My issue is valid with mirror default sample and not specific to my user-mode driver implementation
 I can always reproduce the issue with the provided description bellow
 If I updated Dokan driver (installer or .sys), I tried to restart the computer before my tests
 It can be reproduced on latest release and pre-release

Description
Windows 7 Enterprise pops up a window indicating that the program does not use a signed certificate and cannot be used - uninstall the application.
Logs
Please attach in separate files: mirror output, library logs and kernel logs.
In case of BSOD, please attach minidump or dump analyze output.

Closing comment (2016-03-11T21:43:23Z): Ok, your description seems to be the same as #187
The update should do the job. Everything in the release is signed, it is only a Windows issue.
Repository: dokan-dev/dokany

Issue #640: impersonation: acrobat reader can't open documents from mirror drive mounted from under user's home directory
Created: 2017-12-20T01:42:05Z
I can't open pdfs in Adobe Acrobat Reader DC on a mirror fs if I run mirror as administrator with impersonation on and the root of the mirror fs is under my home directory (c:\Users\Bailey) or in any directory under there (e.g c:\Users\Bailey\Documents, c:\Users\Bailey\Documents\test).
If I run mirror without impersonation, either as administrator or not, I can open pdfs regardless of whether or not the root of the fs is under my home dir.
I've reproduced this problem both on my real Windows 10 64-bit system and in my Virtualbox vm.
The pdf files seem to be completely accessible and can be opened in other pdf readers (e.g. Evince).

Duplicate issue #794: Cannot open pdf file when AppContainer is enabled in Acrobat Reader 2019
Created: 2019-04-04T02:33:25Z
Environment

Windows version: Windows 10 Pro
Processor architecture: x64
Dokany version: 1.2.1.2000
Library type (Dokany/FUSE): Dokany

Check List

[ x] I checked my issue doesn't exist yet
[x ] My issue is valid with mirror default sample and not specific to my user-mode driver implementation
[ x] I can always reproduce the issue with the provided description below.
 I have updated Dokany to the latest version and have reboot my computer after.
 I tested one of the last snapshot from appveyor CI

Description
With the latest version of Acrobat Reader 2019, if "Run in AppContainer" is enabled in the security options of Acrobat Reader, accessing a pdf file in a Dokany virtual drive will report "permission denied" error. The error can be reproduced with the Mirror sample. I think there is some incompatibility between Dokany and Windows' AppContainer mechanism.
Logs

Closing comment (2019-05-11T21:10:49Z): Hi @killing ,
Could it be the same as #640 ?
Repository: dokan-dev/dokany

Issue #355: Mount Manager option show folder as Mounted Volume type
Created: 2016-09-27T10:57:20Z
Feature request can skip this form. Bug report must complete it. Check List must be 100% match or it will be automatically closed without further discussion. Please remove this line.
Environment
Windows version: Win 10
Processor architecture: x64
Dokany version: 1.0.0 RC4
Library type (Dokany/FUSE): Dokany
Check List

[ x] I checked my issue doesn't exist yet
[x ] My issue is valid with mirror default sample and not specific to my user-mode driver implementation
[x ] I can always reproduce the issue with the provided description below.
[x ] I have updated Dokany to the latest version (https://github.com/dokan-dev/dokany/releases) and have reboot my computer after.

Description
When using Mount Manager and check Properties of a Folder you do NOT have Size, Size on disk, Contains props.
Logs
Screenshot attached

Duplicate issue #955: Locally mounted memfs drive shows folders as "mounted volume" in properties
Created: 2021-01-04T12:03:21Z
Feature request can skip this form. Bug report must complete it. Check List must be 100% match or it will be automatically closed without further discussion. Please remove this line.
Environment

Windows version: Windows 10 1909
Processor architecture: x64
Dokany version: 1.4.0
Library type (Dokany/FUSE): Dokany

Check List

 I checked my issue doesn't exist yet
 My issue is valid with mirror default sample and not specific to my user-mode driver implementation
 I can always reproduce the issue with the provided description below.
 I have updated Dokany to the latest version and have reboot my computer after.
 I tested one of the last snapshot from appveyor CI

Description
Mount memfs.exe /l G
Create new folder in g:
copy a file to new folder
Open Properties of new folder
Properties dialog shows Type "Mounted volume" instead of Folder (and does not display size information)
Logs
Please attach in separate files: mirror output, library logs and kernel logs.
In case of BSOD, please attach minidump or dump analyze output.

Closing comment (2021-01-04T12:09:46Z): Hi @uhonermann ,
Thanks for the report. This looks like to be a duplicate of #355
Let me know if you think different and I will reopen the issue.
Repository: dokan-dev/dokany

Issue #611: Excel file(xlsx) save failed in a drive mounted by default mirror sample
Created: 2017-10-24T09:34:35Z
Environment

Windows version:  Win 10 16299(Only)
Processor architecture: 64
Dokany version: 1.0.5
Office version: office 2016
Library type (Dokany/FUSE):  Dokany
Tested program:  default mirror sample in install path

Description
When we edit&save an excel file(xlsx) in a mounted drive, the file will be saved failed.
Reproduce Step

Download & Install Dokany 1.0.5
Mount a drive M(mirror.exe /r C:\Users /l m)
Access drive M and copy A.xlsx to  M
Open & Edit  A.xlsx in M
Save A.xlsx(CTRL + S)
Excel alert says"Because of sharing violation, Microsfte Excel can not saved to  file"M:\F5D42000")

Addition

I can reproduce this issue always
I can save xlsx file on other drive(c:\ or d:) successfully.
"M:\F5D42000" is a temp file created when Excel saving.
Any docx file could not be saved too(similar phenomenon)
Win 10 16299 is  a build released by Microsoft recently, seems it changed a lot.
I can only reproduce this issue on  win 10 16299.
On  win 10 16299, Dokany 2.0.0 beta can't mount a drive M or can't access drive  M after mounted, so i can't test more.

Duplicate issue #610: Excel macro problems
Created: 2017-10-23T12:38:57Z
Environment

Windows version: 10
Processor architecture: x64
Dokany version: 1.0.5
Library type (Dokany/FUSE): Dokany

Check List

 I checked my issue [doesn't exist yet]
 My issue is valid with mirror default sample and not specific to my user-mode driver implementation
 I can always reproduce the issue with the provided description below.
 I have updated Dokany to the latest version and have reboot my computer after.

Description
Try to save this specific excel file doesn't work and force to reboot system.

Open italy_regions.xls
Click on "Protection Advice" and select "Content Activation"
Try to save
italy_regions.zip

Logs
Please attach in separate files: mirror output, library logs and kernel logs.
In case of BSOD, please attach minidump or dump analyze output.
dokan-excel-reboot.log

Closing comment (2017-11-12T15:03:14Z): Hi @gambetto ,
I have reproduce your issue and it seems to be the same as #611
Are you using Win 10 16299 ? (last update)
Repository: dokan-dev/dokany

Issue #154: Thumbnail in Windows 10 not displaying correctly
Created: 2016-02-02T09:50:48Z
Some images do not display correctly the thumbnail in Windows 10 explorer. I have reproduced the behaviour with mirror sample.

For small size files preview is working fine, but for big images like (http://www.artandlemonade.com/wp-content/uploads/2014/06/MG_8940.jpg) it is not.

Duplicate issue #97: Microsoft Photos app in Windows 10 is unable to display pictures
Created: 2015-10-27T23:43:33Z
Hi,
The Microsoft Photos (Microsoft.Photos.exe), default photo viewing app in Windows 10, is not able to display pictures from a dokany-mapped drive. It shows error IMG_xyz.jpg We can't open this file
The issue is easily reproducible using the mirror example (tested on commit c39e712). It happens in local or removable drive mode (/r), network drive mode (/n) seems to be fine. I can provide dokany debug output if needed, but have not spotted any errors in there though.
Cheers, Ivo

Closing comment (2016-04-07T14:16:27Z): Hi @js69 ,
I think your issue is more related to #154
Before the fix of this issue, you was absolutly not able to open a picture at all.
Repository: dokan-dev/dokany

Issue #975: Dokan Mirror remote location issues
Created: 2021-03-07T17:30:27Z
Feature request can skip this form. Bug report must complete it. Check List must be 100% match or it will be automatically closed without further discussion. Please remove this line.
Environment

Windows version: 10
Processor architecture: X64 AMD Ryzen 3700x
Dokany version: 1.2 and up
Library type (Dokany/FUSE): Unknown

Check List

 I checked my issue doesn't exist yet
 My issue is valid with mirror default sample and not specific to my user-mode driver implementation
 I can always reproduce the issue with the provided description below.
 I have updated Dokany to the latest version and have reboot my computer after.
 I tested one of the last snapshot from appveyor CI

Description
Hi,
My apologies if this is not the right place for my issue.
I downloaded the latest version of Dokan in order to map a network drive as local. The latest version is giving me errors while running Mirror.exe. It says: "Cant install drivers". Every version above 1.2.2.2000 does this. Version 1.2.2.2000 and under do not. However they cannot seem to mount the drive properly since I never see any confirmation of the drive being mounted. The drive is mounted and I can acces it but the CMD that I launch it from does not finish the mounting process.
Also when accessing the mounted drive I get an error that tells me there is a buffer issue. There is a buffer too small.
I am not a developer and do not know how to troubleshoot this problem. Any help would me much appreciated.
I do not know how to attach logs.
Logs
Please attach in separate files: mirror output, library logs and kernel logs.
In case of BSOD, please attach minidump or dump analyze output.

Duplicate issue #991: MirrorFS - wrong size output on large samba volume + crash
Created: 2021-05-13T22:49:59Z
Feature request can skip this form. Bug report must complete it. Check List must be 100% match or it will be automatically closed without further discussion. Please remove this line.
Environment

Windows version: Windows 10
Processor architecture: x64
Dokany version: 1.4.1.1000
Library type (Dokany/FUSE): ?

Check List

 I checked my issue doesn't exist yet
 My issue is valid with mirror default sample and not specific to my user-mode driver implementation
 I can always reproduce the issue with the provided description below.
 I have updated Dokany to the latest version and have reboot my computer after.
[-] I tested one of the last snapshot from appveyor CI

Description
Mounting a 10TB samba volume causes the volume to display as (around) 4TB size. Ruled out samba as cause as is it displayed as 10TB if mounted as network volume. Also, Dokany is crashing at 125-144GB when doing right click -> Properties on a subfolder containing data. stderr output reveals nothing, it simply browses through the files and suddenly closes down.
Logs
Please attach in separate files: mirror output, library logs and kernel logs.
In case of BSOD, please attach minidump or dump analyze output.

Closing comment (2021-05-14T05:40:18Z): Hi,
This looks like to be the same as #975
Could you check and let me know ?
Repository: dokan-dev/dokany

Issue #332: Drive letter cannot be reclaimed after killing process with current_session option specified
Created: 2016-09-09T23:26:25Z
Environment

Windows version: windows 7 64-bit
Processor architecture: x64
Dokany version: 1.0.0 rc4
Library type (Dokany/FUSE): Dokany

Check List

 I checked my issue doesn't exist yet
 My issue is valid with mirror default sample and not specific to my user-mode driver implementation
 I can always reproduce the issue with the provided description below.
 I have updated Dokany to the latest version (https://github.com/dokan-dev/dokany/releases) and have reboot my computer after.

Description
Hello,
I noticed an issue that the network share does not get released by the operating system when the user space process gets killed off via the task manager when user_current option is specified.
To reproduce the issue:

run command: mirror.exe /r D:\test -l p /d  /s /n /c /u \test\share
observed the network share is mounted
open task manager and kills mirror.exe
re-run the same mirror.exe command and observes that the same drive letter is no longer available

I have tried the same step without /u and I was able to reclaimed the same drive letter after a few seconds of wait time.
I have attached the mirror.exe output with and without current_session specified.
Logs
mirror_output_with_current_session.txt
mirror_output_without_current_session.txt

Duplicate issue #568: Drive letter becomes unassignable after the program crashed
Created: 2017-09-01T10:44:52Z
Environment

Windows version: win7 sp1
Processor architecture: x64
Dokany version: 1.0.2/1.0.4
Library type (Dokany/FUSE): Dokany

Check List

 I checked my issue doesn't exist yet
 My issue is valid with mirror default sample and not specific to my user-mode driver implementation
 I can always reproduce the issue with the provided description below.
 I have updated Dokany to the latest version and have reboot my computer after.
 I tested one of the last snapshot from appveyor CI

Description
When the file system program that uses dokan crashed (e.g. segfault, or killed in task manager), the drive letter it used can't be assigned anymore. If we try to mount with the old drive letter, we'll get the error "Can't assign a drive letter" (we get the same error if we use mirror.exe to mount to that letter). The only way to get around that is either to use another drive letter, or reboot the system.
After the program crashed, dokanctl /l shows there is no mountpoints in use, and dokanctl /u S with admin privilege (s is the drive letter we use) shows:
c:\Program Files\Dokan\Dokan Library-1.0.4\>dokanctl.exe /u S

Driver path: 'C:\Windows\system32\drivers\dokan1.sys'
send global release for S:
DokanError: Ioctl failed with code 122
Failed to unmount: S:
Unmount status = 1
One interesting thing we note is: after the program crashed and the letter become unassignable, we can run mirror.exe with admin privilege to assign that letter. But if I try to enter the drive from explorer, it would show an error like:

Closing comment (2017-09-01T10:47:05Z): Hi @lins05 ,
Is this the same as #332 ?
Repository: dortania/OpenCore-Legacy-Patcher

Issue #316: Implement Lower Power Mode (LPM) for older Macs in macOS Monterey
Created: 2021-06-19T03:58:45Z
With macOS Monterey, we've been able to unlock both Sidecar and Airplay support for legacy Macs. However we currently do not enable LPM on pre-Skylake Macs. While the majority of the power management benefits are likely tied to hardware, the OS does handle scheduling and limiting applications' CPU usage meaning there can be benefits to enabling on pre-Skylake hardware.
Currently LPM is supported on the following models:

MacBook9,1+
MacBookAir8,1+
MacBookPro13,x+

We believe Apple hard coded hardware support inside /System/Library/PrivateFrameworks/PowerUI.framework/Versions/A/PowerUI. Below is a binary ripped from 12.0:

PowerUI.zip

Note: Compared to SidecarFixup and AirplayCore, Apple did not hard code a full model array into PowerUI. Further investigation required for how Apple handles device checks

Duplicate issue #486: [Enhancement]: Trick monterey into thinking that older macs can use low power mode.
Created: 2021-09-13T00:32:53Z
Machine Model
MacBookPro9,2
Application Version
Latest Release
Application Variant
Other/Non-Applicable
What versions of macOS are you seeing the problem on?
macOS 12, Monterey
Where does this issue happen?
Within macOS (After Logging in)
What is the Isssue?
I heard that monterey got a new low power mode, how ever it does not seem to appear on my 9,2 (probably because it is unsupported) though it would be cool if a feature were to be added to spoof macos in such a way where low power mode would be available
Any Additional Information
No response

Closing comment (2021-09-13T01:34:47Z): Duplicate of #316
Repository: dortania/OpenCore-Legacy-Patcher

Issue #758: A Required firmware update could not be installed
Created: 2021-11-24T18:37:51Z
Machine Model
MacPro5,1
Application Version
Latest Release
Application Variant
TUI (Text User Interface)
Have you verified whether this issue has been opened before? If no, your issue will be closed
true
Have you verified whether this issue is covered in our guide? ie. Troubleshooting and Legacy Acceleration pages
true
Is this issue with a 3rd party application?
false
What versions of macOS are you seeing the problem on?
macOS 12, Monterey
Where does this issue happen?
Other/Non-Applicable
What is the Issue?
Using the command line Patcher (0.3.1)  I boot into EFI - Run the Monterey Installer and when it reboots to finish I get the error: "A required firmware update could not be installed"
I changed the Setting before building to Patcher Setting > SMBIOS Settings >Set SMBIOS Spoof Level = Moderate
and I still get this error.

Any Additional Information
Thank you VERY much for your work on this running Big Sur on My 5,1 mac has been amazing and I am greedy for Monterey.

Duplicate issue #871: A required firmware update could not be installed during updating (macOS Update Assistant)
Created: 2022-01-05T09:21:03Z
Machine Model
MacPro4,1
Application Version
Latest Release
Application Variant
CLI (Command Line Interface)
Have you verified whether this issue has been opened before? If no, your issue will be closed
true
Have you verified whether this issue is covered in our guide? ie. Troubleshooting and Legacy Acceleration pages
true
Is this issue with a 3rd party application?
false
What versions of macOS are you seeing the problem on?
macOS 12, Monterey
Where does this issue happen?
Other/Non-Applicable
What is the Issue?
During installation phase after rebooting, for finishing installation, a firmware update blocked the finalisation of installation, with the message :
A required firmware update could not be installed during updating (macOS Update Assistant)

Any Additional Information
SSD SIP disabled
Video Card NVIDIA GeForce GTX 680 2 Go Metal Apple Edition
32Go Ram

Closing comment (2022-01-05T09:31:12Z): This is a duplicate of #758
Repository: dortania/OpenCore-Legacy-Patcher

Issue #104: MBP9,2 apple try update SMC
Created: 2021-03-15T22:01:40Z
Describe the bug
Upgrading to BS11.3 any beta version apple tried to upgrade smc on MBP9,2 writing again apple directory at EFI, OC obviously blocked the installation , and finished updade to BS11.3 b4 20E5210c
Additional context
Is there any way to show a high number at SMC version  :
current
System firmware version:	9999.999.999.999.999
SMC Version    (system):	2.2f44

Duplicate issue #107: MBP9,2 SMC still try update 
Created: 2021-03-17T10:26:47Z
I've tested in my MBP9,2 and didn't work: Apple still tried to update my SMC, this was blocked by Opencore, everything is working fine, just boot time increased a little.

Closing comment (2021-03-17T13:59:25Z): Duplicate: #104
Repository: dortania/OpenCore-Legacy-Patcher

Issue #452: Disable SecureBootModel flag doesn't work in GUI
Created: 2021-08-20T19:23:52Z
Machine Model
MacBookPro9,2
Application Version
Latest Release
Application Variant
GUI (Graphical User Interface)
What versions of macOS are you seeing the problem on?
macOS 11, Big Sur
Where does this issue happen?
Other/Non-Applicable
What is the Isssue?
when change the "Disable SecureBootModel" flag setting to build and install Opencore using GUI app.Apparently the value always is false on the print out.
Also checking the generated EFI/config.plist file it seems that it isn't modified.
uncheck both to set sip and SecureBootModel enable

SecureBootModel show message "disabling" ( It doesn't matter which flag value you choose )

EFI/config.plist - Misc->Security

Any Additional Information
No response

Duplicate issue #513: [Bug]: Latest Nightly Build Doesn't Disable SIP
Created: 2021-09-27T05:16:54Z
Machine Model
MacPro5,1
Application Version
Latest Build (nightly)
Application Variant
GUI (Graphical User Interface)
What versions of macOS are you seeing the problem on?
macOS 11, Big Sur
Where does this issue happen?
Within macOS (After Logging in)
What is the Isssue?
On the latest nightly build (8f98cac), I disabled SIP in the GUI settings as follows:

However, I still get the following output from csrutil status (showing that it was not fully disabled):
System Integrity Protection status: unknown (Custom Configuration).

Configuration:
	Apple Internal: disabled
	Kext Signing: disabled
	Filesystem Protections: disabled
	Debugging Restrictions: enabled
	DTrace Restrictions: enabled
	NVRAM Protections: enabled
	BaseSystem Verification: enabled

This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.

This has also happened on another machine using the latest nightly build (8f98cac). Any ideas on how to fix this?
Any Additional Information
No response

Closing comment (2021-09-29T17:55:06Z): Duplicate: #452
Repository: dortania/OpenCore-Legacy-Patcher

Issue #661: [Bug]: iMac14,1 doesn't output signal over mDP to external monitor with OCLP 0.3.0 or above
Created: 2021-10-29T17:35:27Z
Machine Model
iMac14,1
Application Version
Latest Release
Application Variant
TUI (Text User Interface)
What versions of macOS are you seeing the problem on?
macOS 11, Big Sur
Where does this issue happen?
Within macOS (Before Logging in)
What is the Isssue?
Hello!
iMac14,1 doesn't output signal over mDP to external monitor with OCLP 0.3.0 or 0.3.1. External display works fine with OCLP 0.2.5 and 0.2.4.
Since I don't know any better, I'm diff'ed EFI/OC/config.plist between OCLP 0.2.5. and 0.3.0.
I'll try copying entires from the older config to the newer one bit by bit to see if anything fixes it. Shouldn't take too long since there are only a few differences. Think I'll start with NVRAM entries, then SMBIOS. The rest of the entries (board ids, etc) seem to be connected with the change from spoofed iMac16,1 to iMac17,1.
Please do let me know if anyone has a better idea how to troubleshoot this. Any help would be appreciated!
Thank you for your efforts :)
Any Additional Information
No response

Duplicate issue #664: [Bug]: iMac 14,4 Thunderbolt HDMI doesn't work
Created: 2021-10-30T01:16:07Z
Machine Model
iMac14,4
Application Version
Latest Build (nightly)
Application Variant
TUI (Text User Interface)
What versions of macOS are you seeing the problem on?
macOS 12, Monterey
Where does this issue happen?
Within macOS (After Logging in)
What is the Isssue?
Hi. I just installed macOs Monterey with the OpenCore Legacy Patcher v0.3.1, in the iMac 14,4. The HDMI external monitor/TV isn't working.
I tried different things, but nothing seems help. if somebody can help me, i attach my config.plist. Thanks
config.plist.zip
Any Additional Information
No response

Closing comment (2021-10-30T01:55:40Z): Duplicate:

#661
Repository: dotnet/Silk.NET

Issue #1697: Embed OpenAL Library Files for Mac/Linux
Created: 2023-10-08T08:51:14Z
Summary of feature
Simply embeds the library files into the EXE file  for Mac/Linux just like it does for Windows so that no one has to manually mess with projects settings and grab the  library files .
Comments
Ill admit Im being a bit lazy but I bet Im not the only who thinks having a million dll's for a final  release is a mess.
Does this have a proposal?
Include the library files for Linux/Mac single file publish just like it is for Windows.

Duplicate issue #1698: OpenAL Linux/Mac Library Files not being included on publish
Created: 2023-10-08T21:21:45Z
Summary of feature
This is re-issue of issue that was immedilatly closed (#1697 and yes I already had everything setup in project/publish settings otherwise my program wouldn't have worked regardless if I was using Silk.NET) next time please dont just immediatly close issues , I wouldn't have opened either of these issues unless I know there was a problem. I guess Ill try to explain a bit more depth what the issue is. So normally when I want write a .NET 6 cross platform app I go to publish and then select the platform I want to publish for (mac , linux etc). Depending on witch platform I select the libraries (that generally get via nugget) I include in my C# project the libraries simply include different library files (dll,so files etc) based on the platform I am publishing for. However for some reason with Silk.NET (more specficly openAL) it doesnt include the propery library files if I publish for anything other than windows so if I try to run the program Ill get an error as soon as it tries to run any code that uses Silk.NET. Now I could just go in the source code and grab the correct library files (libopenal.so and libopenal.dylib in my case) and just copy them to the same directory as the Linux and Mac EXE witch fixes the problems. I could also just force users to just install openAL but I dont like doing that (especally for linux cause of all the distros). But preferable this should all be taken care of by the libraries and not by me copying library files and messing with my the files included in my project. Anyways hopefully you folks understand what Im talking about.
Does this have a proposal?
just have the library files be include on linux/mac publish by default just like it is for Windows publish.

Closing comment (2023-10-08T21:25:03Z): Closing as duplicate of #1697
Repository: dotnet/Silk.NET

Issue #305: Trimming
Created: 2020-09-03T07:57:40Z
In addition to the work done in #303 we should consider trimming. Our assemblies are already very large, so trimming would be of great use.
See https://devblogs.microsoft.com/dotnet/customizing-trimming-in-net-core-5/

Duplicate issue #541: Enable Trimming
Created: 2021-07-05T20:16:44Z
See the docs for trimming. Doing so is breaking and we therefore need to do it until 3.0 - and probably throughout the 3.0 development cycle.

Closing comment (2021-07-05T20:47:51Z): Duplicate of #305
Repository: dotnet/Silk.NET

Issue #813: Direct2D/DirectWrite/WIC support?
Created: 2022-02-17T07:13:37Z
Summary of feature
Silk.NET should have Direct2D/DirectWrite/WIC support.

 Direct2D (#1000)
 DirectWrite (introduced in #1349 and reworked in #1341)
 WIC

Does this have a proposal?
Hope it will be in 3.0
These can be related:
#808
#809

Duplicate issue #1263: DirectWrite and WIC
Created: 2023-01-31T15:11:15Z
please add DirectWrite and WIC
my project uses ID2D1RenderTarget so also need IDWriteFactory and IWICImagingFactory
now temporarily using some api from Vortice but I don't like this approach

Closing comment (2023-02-01T12:51:48Z): Duplicate of #813
Repository: dotnet/Silk.NET

Issue #48: Tracking issue for Silk.NET 2.0
Created: 2019-08-14T23:28:19Z
Development

 [Complete] DirectX and Windows bindings  (!!!!!! MORE !!!!!!) - @Perksey
 [Complete] Assimp bindings - @Perksey
 [Complete] Android support - @Perksey
 [Complete] iOS support (!!!!! NEEDS ROBUSTNESS IMPROVEMENTS ASAP !!!!!) - @Perksey
 [Complete] SDL support - @Perksey
 [Complete] Maths library - @HurricanKai
 [Complete] Bindings generator overhaul - @Perksey
 [Complete] OpenXR bindings - @Perksey
 [Complete] Function pointer interop source generator - @HurricanKai
 [Complete] Overload overhaul (as discussed in 14/08/2020's meeting) - @Perksey

Milestones

 Preview 1 with Assimp and experimental OpenXR bindings (July 2020)
 Preview 2 with SDL bindings/windowing support and new interop (Update Friday September August 2020)
 Preview 3 with mobile windowing support (Early October Early November 2020)
 Preview 4 with Maths, as well as DirectX bindings (Early December 2020)
 Preview 5 release candidate (Late December 2020)
 Full release 🎉 (New Year's Day 2021)

Dates are a loose estimate and are subject to change.

Duplicate issue #49: Mobile support
Created: 2019-08-18T10:30:55Z
EGL window platform (for Android) - Silk.NET.Windowing.Android
 EAGL window platform (for Apple) - Silk.NET.Windowing.Apple

Closing comment (2020-05-20T21:18:58Z): Closing, as this is pretty much tracked by #48 now
Repository: dotnet/Silk.NET

Issue #458: Better naming for generated Vulkan enum and flag values
Created: 2021-04-17T20:09:12Z
Summary of feature
The generated enum values (regardless if bitflag or not) are often unnecessary long. For example in https://github.com/dotnet/Silk.NET/blob/main/src/Vulkan/Silk.NET.Vulkan/Enums/DebugUtilsMessageSeverityFlagsEXT.gen.cs
where the full name of the enum is a prefix of every value for example "DebugUtilsMessageSeverityVerboseBitExt".
This leads to extremly long code.
Some of the enums are handled in a more C# way, like https://github.com/dotnet/Silk.NET/blob/main/src/Vulkan/Silk.NET.Vulkan/Enums/StructureType.gen.cs where the prefix was removed.
Could all enums (and therefor flags) be handled like StructureType as well or are there reasons why not?
My suggestion would be:

for all enum values to remove the common prefix (without the extension) and the extension at the end.
for all flag values to remove the common prefix (without Flags and extension) and Bit + extension at the end.

Comments

I would like to help if needed, but got lost in the BuildTools project.
A general naming scheme might need to be discussed upfront:

Keep extension name (KHR, EXT, etc.) on value names or remove them?
Always remove prefix or are there exceptions?



Does this have a proposal?
Not as of now.

Duplicate issue #728: Named issues about FormatB8G8R8A8Unorm
Created: 2021-12-22T07:26:18Z
I think it should be UNorm not Unorm.
The UNorm means two words: unsigned-normalized.

Closing comment (2021-12-22T07:45:41Z): Closing as “won’t fix” (and duplicate of #458 same underlying cause)
I agree, but

these are generated bindings so we will have to special case these in the generator. Not a problem, but
this would be a breaking change, which we are not prepared to do at this time.
at least we’re consistently wrong throughout the library.

We will one day try and fix this as part of #458, but in the short/mid-term this will not be fixed.
Repository: dotnet/Silk.NET

Issue #163: Consider updating how fixed-sized buffers for non-primitive types are bound
Created: 2020-04-05T00:10:29Z
Fixed sized buffers in C# only support a limited subset of types today: bool, byte, char, short, int, long, sbyte, ushort, uint, ulong, float, or double.
While there exists proposals for extending this to support other types as well, that support does not currently exist. This can make it difficult to work with certain structures such as D3D12_RT_FORMAT_ARRAY:
struct D3D12_RT_FORMAT_ARRAY {
  DXGI_FORMAT RTFormats[8];
  UINT        NumRenderTargets;
};
Today, Silk.NET is generating an inline array of fields for these (similar to and based on https://discordapp.com/channels/521092042781229087/587346162802229298/696144071164428348):
struct D3D12_RT_FORMAT_ARRAY
{
  public DXGI_FORMAT RTFormats_0;
  public DXGI_FORMAT RTFormats_1;
  public DXGI_FORMAT RTFormats_2;
  public DXGI_FORMAT RTFormats_3;
  public DXGI_FORMAT RTFormats_4;
  public DXGI_FORMAT RTFormats_5;
  public DXGI_FORMAT RTFormats_6;
  public DXGI_FORMAT RTFormats_7;
  public uint NumRenderTargets;
}
Instead, it may be possible to provide a "nicer" API by abusing some of the unsafe framework APIs:
public partial struct D3D12_RT_FORMAT_ARRAY
{
    [NativeTypeName("DXGI_FORMAT [8]")]
    public _RTFormats_e__FixedBuffer RTFormats;

    [NativeTypeName("UINT")]
    public uint NumRenderTargets;

    public partial struct _RTFormats_e__FixedBuffer
    {
        internal DXGI_FORMAT e0;
        internal DXGI_FORMAT e1;
        internal DXGI_FORMAT e2;
        internal DXGI_FORMAT e3;
        internal DXGI_FORMAT e4;
        internal DXGI_FORMAT e5;
        internal DXGI_FORMAT e6;
        internal DXGI_FORMAT e7;

        public ref DXGI_FORMAT this[int index] => ref AsSpan()[index];

        public Span<DXGI_FORMAT> AsSpan() => MemoryMarshal.CreateSpan(ref e0, 8);
    }
}
This is abusing the MemoryMarshal.CreateSpan API to create a Span around the entire buffer and bypasses the normal C# language safety rules which would prevent this from occuring.
Because it is normally illegal C#, it is not recommended to expose the ref or Span as part of a "safe" API surface and it would be recommended to provide an analyzer that helps remind users that storing the ref/Span will not be tracked appropriately by the language and the ref/Span could outlive the actual backing struct if not managed appropriately.
It's also worth noting that the language could get proper support for this eventually, in which case the exposed signature may need to change slightly or in an incompatible way (depending on if they require any modreq/modopt, etc).

Duplicate issue #164: Add Types and Heaps Array in Vulkan Binding
Created: 2020-04-05T15:39:10Z
Summary of feature
Would it be possible to add arrays like in the original Vulkan API to Silk.NET.Vulkan.PhysicalDeviceMemoryProperties.cs
public MemoryType[] MemoryTypes;
public MemoryHeap[] MemoryHeaps;
It will reduce our code base a lot, because we don't have to create an array of it/switch through the struct anymore.

Closing comment (2020-04-05T15:40:30Z): Duplicate of #163
Repository: dotnet/Silk.NET

Issue #305: Trimming
Created: 2020-09-03T07:57:40Z
In addition to the work done in #303 we should consider trimming. Our assemblies are already very large, so trimming would be of great use.
See https://devblogs.microsoft.com/dotnet/customizing-trimming-in-net-core-5/

Duplicate issue #1730: The library is ready for native aot / net 8? Trimmer annotation required
Created: 2023-10-16T21:49:08Z

Closing comment (2023-10-16T22:08:55Z): Duplicate of #305
Repository: dotnet/diagnostics

Issue #3095: dotnet dump: add support to save output log to a file
Created: 2022-05-29T21:30:23Z
Background and Motivation
When doing complicated analysis, it can be difficult to both be able to reference large outputs (dumpheap) to copy/paste addresses (require a lot of scrolling up and down) and to share results of analysis with other people.
Proposed Feature
Add support to save all console output to a log file, similar to .logopen command in windbg.
Usage Examples
> logopen D:/debug.log

Duplicate issue #2808: dotnet-dump analyze output to file
Created: 2022-01-11T23:14:48Z
Due to the way we interact with dotnet-dump analyze it would great to have a feature were we could output the results of a command to a file on the disk.
This feature would be similar to Out-File command from Microsoft.PowerShell.Core or similar to STDERR/STDOUT from C++ Redirecting from Command Prompt.
Would be willing to work on this if i get a recommendation where in the project this should be implemented.

Closing comment (2022-07-14T21:33:58Z): dup of #3095
Repository: dotnet/diagnostics

Issue #2903: E2E guide how to collect a dump and debug it with VS or LLDB
Created: 2022-03-04T21:14:58Z
Walkthrough: see #515

Duplicate issue #2910: Debugging dumps with cross-platform DAC.
Created: 2022-03-04T22:54:08Z
Walkthrough: see #515

Closing comment (2022-06-06T21:55:48Z): Closing - the customer workflow for debugging x-plat dumps is the same as #2903