maharmstone / btrfs Goto Github PK

Adding official ARM support for Winbtrfs, it works already after adding an ARM sln config

I tried WinBTRFS in the following scenario:

• Windows 7 x64 Build 7601 (latest SP, all patches up to May 2nd 2016)
• Since I didn't have a pre-existing disk with btrfs (and since there's no mkfs.btrfs for Windows yet) I created a new 4gb VHD in the disk management
• I attached the VHD file to a Ubuntu 14.10 VM running in VMware Workstation 11 as "physical disk"
• I booted the VM, partitioned the VHD file and created a (default) btrfs on it and shut down the VM again
• I then removed the VHD from it and did a rescan in the Windows disk manager
• The partition did show up in Disk Management almost immediately
• When clicking on the (newly partitioned) VHD disk I got a bluescreen. Here's the dump log

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - Die Anweisung in 0x%08lx verweist auf Speicher 0x%08lx. Der Vorgang %s konnte nicht im Speicher durchgef hrt werden.

FAULTING_IP: 
FsDepends!DepFSInstanceSetup+25f
fffff880`09feda17 488b4110        mov     rax,qword ptr [rcx+10h]

CONTEXT:  fffff8800d942960 -- (.cxr 0xfffff8800d942960)
rax=fffffa80068babb0 rbx=fffff8800d943410 rcx=0000000000000000
rdx=0000000000000000 rsi=0000000000000001 rdi=0000000000000000
rip=fffff88009feda17 rsp=fffff8800d943340 rbp=0000000000000005
 r8=0000000080000005  r9=fffff80003e0f000 r10=fffff88003507be0
r11=fffff8800d943240 r12=0000000000000078 r13=0000000000000000
r14=0000000000000000 r15=0000000000000008
iopl=0         nv up ei pl zr na po nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
FsDepends!DepFSInstanceSetup+0x25f:
fffff880`09feda17 488b4110        mov     rax,qword ptr [rcx+10h] ds:002b:00000000`00000010=????????????????
Resetting default scope

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0x3B

PROCESS_NAME:  vds.exe

CURRENT_IRQL:  0

LAST_CONTROL_TRANSFER:  from fffff88001500116 to fffff88009feda17

STACK_TEXT:  
fffff880`0d943340 fffff880`01500116 : fffffa80`0e441a40 fffffa80`07172cb0 00000000`00000005 fffff880`0d9435e8 : FsDepends!DepFSInstanceSetup+0x25f
fffff880`0d9433f0 fffff880`014ff11b : 00000000`00000000 fffffa80`0e206810 00000000`00000000 fffffa80`0e441a40 : fltmgr!FltpDoInstanceSetupNotification+0x86
fffff880`0d943450 fffff880`014ffed1 : fffff8a0`183733d0 ffffffff`80003940 fffff8a0`00000005 00000000`000007ff : fltmgr!FltpInitInstance+0x27b
fffff880`0d9434c0 fffff880`01500dab : fffff8a0`1cab8200 00000000`00000000 00000000`00000050 00000000`0000001a : fltmgr!FltpCreateInstanceFromName+0x1d1
fffff880`0d943590 fffff880`014fedbc : fffffa80`07172cc0 fffffa80`07515ac0 fffffa80`07172cc0 00000000`00000022 : fltmgr!FltpEnumerateRegistryInstances+0x15b
fffff880`0d943630 fffff880`014fa3f0 : fffffa80`0e206810 fffffa80`00000000 fffffa80`07172cc0 fffffa80`07515ac0 : fltmgr!FltpDoFilterNotificationForNewVolume+0xec
fffff880`0d9436a0 fffff800`0418643b : 00000000`00000025 00000000`00000040 fffffa80`0cab92c0 00000000`00000000 : fltmgr!FltpCreate+0x3e0
fffff880`0d943750 fffff800`0418244e : fffffa80`0b0154f0 00000000`00000000 fffffa80`0d0a4010 00000000`00000001 : nt!IopParseDevice+0x14e2
fffff880`0d9438b0 fffff800`04182f36 : 00000000`00000000 fffff880`0d943a30 fffff880`00000040 fffffa80`066598e0 : nt!ObpLookupObjectName+0x784
fffff880`0d9439b0 fffff800`0418483c : 00000000`00000000 00000000`00000000 fffffa80`0c49e201 ffffffff`ffffffff : nt!ObOpenObjectByName+0x306
fffff880`0d943a80 fffff800`0418feb4 : 00000000`0230f678 00000000`80100080 00000000`0230f6c8 00000000`0230f688 : nt!IopCreateFile+0x2bc
fffff880`0d943b20 fffff800`03e82313 : 00000000`00000000 0000007f`ffffffff 00000000`00000000 00000980`00000000 : nt!NtCreateFile+0x78
fffff880`0d943bb0 00000000`76ebd90a : 000007fe`fcc348b6 00000000`00000000 00000000`80000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`0230f5f8 000007fe`fcc348b6 : 00000000`00000000 00000000`80000000 00000000`00000000 00000000`00000000 : ntdll!ZwCreateFile+0xa
00000000`0230f600 00000000`76c60dad : 00000000`0230fad0 00000000`80000000 00000000`00000003 000007fe`fec3b52b : KERNELBASE!CreateFileW+0x2cd
00000000`0230f760 000007fe`e2fb978d : 00000000`00000000 00000000`003388f0 00000000`00000003 00000000`0230fad0 : kernel32!CreateFileWImplementation+0x7d
00000000`0230f7c0 000007fe`e2fb9aa9 : 00000000`00000000 00000000`00000000 00000000`003388f0 00000000`0230fc68 : vdsdyn!DynOpenDevice+0x13d
00000000`0230fa80 000007fe`e2fe70fc : 00000000`00000000 00000000`00000000 00000000`00000000 000007fe`e2fe7014 : vdsdyn!DynGetVolumeDeviceNumber+0x7d
00000000`0230fc50 00000000`76c659ed : 00000000`00000000 00000000`000f423f 00000000`00000000 00000000`00000000 : vdsdyn!g_ProcessPnpNotification+0xe8
00000000`0230fcc0 00000000`76e9b371 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0xd
00000000`0230fcf0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x1d


FOLLOWUP_IP: 
FsDepends!DepFSInstanceSetup+25f
fffff880`09feda17 488b4110        mov     rax,qword ptr [rcx+10h]

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  FsDepends!DepFSInstanceSetup+25f

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: FsDepends

IMAGE_NAME:  FsDepends.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4a5bc295

STACK_COMMAND:  .cxr 0xfffff8800d942960 ; kb

FAILURE_BUCKET_ID:  X64_0x3B_FsDepends!DepFSInstanceSetup+25f

BUCKET_ID:  X64_0x3B_FsDepends!DepFSInstanceSetup+25f

Followup: MachineOwner
---------

Hi. No drivers binary? Only compiling?

Thanks!

It seems there is some work being done by the people working on ReactOS to add this driver to it.
I'd like to see this happen, as I think it will likely be helpful both for ReactOS, and for btrfs, and specifically this btrfs for Windows implementation .
See Jira:CORE-10892 for what they have so far, and hopefully any changes required for ReactOS integration can be merged upstream (into this codebase) so that keeping it up-to-date in the ReactOS codebase is easy (meaning that it will be more likely to actually be updated when this implementation gets updates).

Thank you for making this, and please keep up the good work.

So I accidentally did a mkbtrfs on an existing volume which caused a bluescreen. After reboot the volume wasn't accessible anymore and I had problems creating new partitions. This was on Windows 7 x64 with version 0.8.
It also bluescreens if I delete a volume with btrfs on it in the volume manager.
Tell me if you need logs or stack straces. Thanks!

Using Linux: SystemRescueCd 4.7.2(Linux sysresccd 3.18.29-std472-amd64)
Using Windows: Windows 10 1511 x86, Windows 7 SP1 x64

BSoD has occurred in a high probability the following procedure.

# mkfs.btrfs -f -m single /dev/sdb1
btrfs-progs v4.4.1
See http://btrfs.wiki.kernel.org for more information.

Performing full device TRIM (125.73GiB) ...
Label:              (null)
UUID:               c26df1b0-1647-44cb-b23d-005fe53d0e05
Node size:          16384
Sector size:        4096
Filesystem size:    125.73GiB
Block group profiles:
  Data:             single            8.00MiB
  Metadata:         single            8.00MiB
  System:           single            4.00MiB
SSD detected:       no
Incompat features:  extref, skinny-metadata
Number of devices:  1
Devices:
   ID        SIZE  PATH
    1   125.73GiB  /dev/sdb1

# mount -r /dev/sdb1 tmp
# ls /sys/fs/btrfs/*/features/
big_metadata extended_iref mixed_backref skinny_metadata

# reboot

Open elevated command prompt.
C:\btrfs> reg add HKLM\SYSTEM\CurrentControlSet\Services\btrfs /v DebugLogLevel /t REG_DWORD /d 2 /f
...
C:\btrfs> loader
...
C:\btrfs> fsutil file createnew D:\test 1073741824
Error: There is not enough space on the disk

Then, repeat copy file to btrfs volume or above fsutil.
Windows died with SYSTEM_THREAD_EXCEPTION_NOT_HANDLED or BAD_POOL_CALLER.

btrfs.log(10 x86, DebugLogLevel=2, I could not set DebugLogLevel=3, because cause KMODE_EXCEPTION_NOT_HANDLED at loading driver.)

Starting logging at 2016-05-24 14:25:22
0000009C:mount_vol:generation was 5, free-space cache generation was ffffffffffffffff; clearing cache...
00000B4C:insert_prealloc_extent:couldn't find any data chunks with 40000000 bytes free
00000B4C:extend_file:insert_prealloc_extent returned c000007f
00000B4C:set_end_of_file_information:error - extend_file failed
00000B28:mount_vol:error reading partition information: c0000010
00000B28:mount_vol:error reading partition information: c0000010
000006D0:open_file:SeAccessCheck failed, returning c0000061
000006D0:open_file:SeAccessCheck failed, returning c0000022
000006D0:open_file:SeAccessCheck failed, returning c0000022
000006D0:open_file:SeAccessCheck failed, returning c0000061
000006D0:drv_read:tried to read zero bytes
000006D0:open_file:SeAccessCheck failed, returning c0000022
000006D0:open_file:SeAccessCheck failed, returning c0000022
00000F0C:_find_item:find_item_in_tree returned c00000e5
00000F0C:_find_item:find_item_in_tree returned c00000e5
00000B28:open_file:SeAccessCheck failed, returning c0000022
00000B28:open_file:SeAccessCheck failed, returning c0000022
00000B00:open_file:SeAccessCheck failed, returning c0000022
00000B00:open_file:SeAccessCheck failed, returning c0000022
00000B7C:open_file:SeAccessCheck failed, returning c0000022
00000B7C:open_file:SeAccessCheck failed, returning c0000022
00000B64:open_file:SeAccessCheck failed, returning c0000022
00000B64:open_file:SeAccessCheck failed, returning c0000022
00000E8C:drv_device_control:STUB: device control
00000E8C:drv_device_control:control code = 4d0008
00000E8C:drv_device_control:STUB: device control
00000E8C:drv_device_control:control code = 4d0008
00000DE0:update_chunk_usage:could not find (1400000,c0,40000000) in extent_root

btrfs.log(7 x64, DebugLogLevel=3)

Starting logging at 2016-05-24 18:11:25
0000000000000038:DriverEntry:DriverEntry
0000000000000038:check_cpu:SSE4.2 is supported
0000000000000038:test_vol:HarddiskVolume1
0000000000000038:test_vol:\Device\HarddiskVolume1
0000000000000038:test_vol:volume found
0000000000000038:test_vol:FS uuid f19ed2f8-ee50-453c-997d-8b923c6d93b9
0000000000000038:test_vol:device uuid b9c1524f-df16-4f4b-87e6-6d480d3d9903
0000000000000038:test_vol:device number 1
0000000000000038:test_vol:HarddiskVolume2
0000000000000038:test_vol:\Device\HarddiskVolume2
0000000000000038:test_vol:HarddiskVolumeShadowCopy1
0000000000000038:test_vol:\Device\HarddiskVolumeShadowCopy1
0000000000000038:test_vol:HarddiskVolume3
0000000000000038:test_vol:\Device\HarddiskVolume3
0000000000000038:test_vol:HarddiskVolume4
0000000000000038:test_vol:\Device\HarddiskVolume4
0000000000000038:add_volume:found BTRFS volume
0000000000000038:add_volume:mmdlt = \Device\HarddiskVolume1
0000000000000038:add_volume:DriveLetterWasAssigned = 0, CurrentDriveLetter = D
0000000000000040:drv_file_system_control:file system control
0000000000000040:drv_file_system_control:IRP_MN_MOUNT_VOLUME
0000000000000040:mount_vol:mount_vol called
0000000000000040:mount_vol:partition length = 1857028096
0000000000000040:read_superblock:got superblock 0!
0000000000000040:read_superblock:got superblock 1!
0000000000000040:read_superblock:crc32 was 18c5c756, expected 18c5c756
0000000000000040:read_superblock:label is 
0000000000000040:mount_vol:btrfs magic found
0000000000000040:mount_vol:DeviceToMount = FFFFFA83030A6040
0000000000000040:mount_vol:Stack->Parameters.MountVolume.Vpb = FFFFFA83047BB5A0
0000000000000040:load_sys_chunks:bootstrap: 100,e4,0
0000000000000040:_find_item:(FFFFFA8302259180, FFFFF8A002482010, FFFFF880039FBD80, FFFFF880039FBD40)
0000000000000040:_load_tree:(FFFFFA8302259180, 20000)
0000000000000040:find_device_from_uuid:device 0, uuid b9c1524f-df16-4f4b-87e6-6d480d3d9903
0000000000000040:find_device_from_uuid:returning device 0
0000000000000040:_load_tree:returning FFFFF8A001604010
0000000000000040:find_item_in_tree:(FFFFFA8302259180, FFFFF8A001604010, FFFFF880039FBD80, FFFFF880039FBD40, 0)
0000000000000040:load_chunk_root:(1,d8,1)
0000000000000040:load_chunk_root:(100,e4,0)
0000000000000040:find_device_from_uuid:device 0, uuid b9c1524f-df16-4f4b-87e6-6d480d3d9903
0000000000000040:find_device_from_uuid:returning device 0
0000000000000040:load_chunk_root:device 0 = FFFFF8A00180B010
0000000000000040:load_chunk_root:(100,e4,400000)
0000000000000040:find_device_from_uuid:device 0, uuid b9c1524f-df16-4f4b-87e6-6d480d3d9903
0000000000000040:find_device_from_uuid:returning device 0
0000000000000040:load_chunk_root:device 0 = FFFFF8A00180B010
0000000000000040:load_chunk_root:(100,e4,c00000)
0000000000000040:find_device_from_uuid:device 0, uuid b9c1524f-df16-4f4b-87e6-6d480d3d9903
0000000000000040:find_device_from_uuid:returning device 0
0000000000000040:load_chunk_root:device 0 = FFFFF8A00180B010
0000000000000040:_find_item:(FFFFFA8302259180, FFFFF8A001814DE0, FFFFF880039FBD90, FFFFF880039FBD60)
0000000000000040:_load_tree:(FFFFFA8302259180, 404000)
0000000000000040:_load_tree:returning FFFFF8A001B461D0
0000000000000040:find_item_in_tree:(FFFFFA8302259180, FFFFF8A001B461D0, FFFFF880039FBD90, FFFFF880039FBD60, 0)
0000000000000040:look_for_roots:(2,84,0)
0000000000000040:look_for_roots:root 2 - address 408000
0000000000000040:look_for_roots:(4,84,0)
0000000000000040:look_for_roots:root 4 - address 420000
0000000000000040:look_for_roots:(5,c,6)
0000000000000040:look_for_roots:(5,84,0)
0000000000000040:look_for_roots:root 5 - address 400000
0000000000000040:look_for_roots:(6,1,0)
0000000000000040:look_for_roots:(6,c,6)
0000000000000040:look_for_roots:(6,54,8dbfc2d2)
0000000000000040:look_for_roots:(7,84,0)
0000000000000040:look_for_roots:root 7 - address 424000
0000000000000040:look_for_roots:(fffffffffffffff7,84,0)
0000000000000040:look_for_roots:root fffffffffffffff7 - address 428000
0000000000000040:_find_item:(FFFFFA8302259180, FFFFF8A001814BB0, FFFFF880039FBDA8, FFFFF880039FBD78)
0000000000000040:_load_tree:(FFFFFA8302259180, 408000)
0000000000000040:_load_tree:returning FFFFF8A0018483B0
0000000000000040:find_item_in_tree:(FFFFFA8302259180, FFFFF8A0018483B0, FFFFF880039FBDA8, FFFFF880039FBD78, 0)
0000000000000040:find_chunk_usage:chunk 0 has 4000 bytes used
0000000000000040:load_free_space_cache:generating free space cache for chunk 0
0000000000000040:_find_item:(FFFFFA8302259180, FFFFF8A001814BB0, FFFFF880039FBCD0, FFFFF880039FBC88)
0000000000000040:find_item_in_tree:(FFFFFA8302259180, FFFFF8A0018483B0, FFFFF880039FBCD0, FFFFF880039FBC88, 0)
0000000000000040:load_free_space_cache:(0,20000)
0000000000000040:load_free_space_cache:(24000,3dc000)
0000000000000040:load_free_space_cache:0,20000,0
0000000000000040:load_free_space_cache:20000,4000,1
0000000000000040:load_free_space_cache:24000,3dc000,0
0000000000000040:protect_superblocks:cut out superblock in chunk 0
0000000000000040:add_to_space_list:(FFFFF8A0018385C0, 10000, 10000, 1)
0000000000000040:add_to_space_list:0,20000,0
0000000000000040:add_to_space_list:20000,4000,1
0000000000000040:add_to_space_list:24000,3dc000,0
0000000000000040:add_to_space_list:0,10000,0
0000000000000040:add_to_space_list:10000,14000,1
0000000000000040:add_to_space_list:24000,3dc000,0
0000000000000040:_find_item:(FFFFFA8302259180, FFFFF8A001814BB0, FFFFF880039FBDA8, FFFFF880039FBD78)
0000000000000040:find_item_in_tree:(FFFFFA8302259180, FFFFF8A0018483B0, FFFFF880039FBDA8, FFFFF880039FBD78, 0)
0000000000000040:find_chunk_usage:chunk 400000 has 18000 bytes used
0000000000000040:load_free_space_cache:generating free space cache for chunk 400000
0000000000000040:_find_item:(FFFFFA8302259180, FFFFF8A001814BB0, FFFFF880039FBCD0, FFFFF880039FBC88)
0000000000000040:find_item_in_tree:(FFFFFA8302259180, FFFFF8A0018483B0, FFFFF880039FBCD0, FFFFF880039FBC88, 0)
0000000000000040:load_free_space_cache:(40c000,14000)
0000000000000040:load_free_space_cache:(42c000,7d4000)
0000000000000040:load_free_space_cache:400000,c000,1
0000000000000040:load_free_space_cache:40c000,14000,0
0000000000000040:load_free_space_cache:420000,c000,1
0000000000000040:load_free_space_cache:42c000,7d4000,0
0000000000000040:_find_item:(FFFFFA8302259180, FFFFF8A001814BB0, FFFFF880039FBDA8, FFFFF880039FBD78)
0000000000000040:find_item_in_tree:(FFFFFA8302259180, FFFFF8A0018483B0, FFFFF880039FBDA8, FFFFF880039FBD78, 0)
0000000000000040:find_chunk_usage:chunk c00000 has 0 bytes used
0000000000000040:load_free_space_cache:generating free space cache for chunk c00000
0000000000000040:_find_item:(FFFFFA8302259180, FFFFF8A001814BB0, FFFFF880039FBCD0, FFFFF880039FBC88)
0000000000000040:find_item_in_tree:(FFFFFA8302259180, FFFFF8A0018483B0, FFFFF880039FBCD0, FFFFF880039FBC88, 0)
0000000000000040:load_free_space_cache:(c00000,800000)
0000000000000040:load_free_space_cache:c00000,800000,0
0000000000000040:mount_vol:generation was 5, free-space cache generation was ffffffffffffffff; clearing cache...
0000000000000040:_find_item:(FFFFFA8302259180, FFFFF8A001814DE0, FFFFF880039FBD90, FFFFF880039FBD50)
0000000000000040:find_item_in_tree:(FFFFFA8302259180, FFFFF8A001B461D0, FFFFF880039FBD90, FFFFF880039FBD50, 0)
0000000000000040:_find_item:(FFFFFA8302259180, FFFFF8A0011D3DE0, FFFFF880039FBF08, FFFFF880039FBE30)
0000000000000040:_load_tree:(FFFFFA8302259180, 400000)
0000000000000040:_load_tree:returning FFFFF8A001B11640
0000000000000040:find_item_in_tree:(FFFFFA8302259180, FFFFF8A001B11640, FFFFF880039FBF08, FFFFF880039FBE30, 0)
0000000000000040:get_xattr:(FFFFFA8302259180, 5, 100, security.NTACL, 45922146, FFFFF8A00160CC98, FFFFF880039FBC68)
0000000000000040:_find_item:(FFFFFA8302259180, FFFFF8A0011D3DE0, FFFFF880039FBBC0, FFFFF880039FBB90)
0000000000000040:find_item_in_tree:(FFFFFA8302259180, FFFFF8A001B11640, FFFFF880039FBBC0, FFFFF880039FBB90, 0)
0000000000000040:get_xattr:could not find item (100,18,45922146)
0000000000000040:get_xattr:(FFFFFA8302259180, 5, 100, user.DOSATTRIB, 914f9939, FFFFF880039FBDA8, FFFFF880039FBDB0)
0000000000000040:_find_item:(FFFFFA8302259180, FFFFF8A0011D3DE0, FFFFF880039FBD20, FFFFF880039FBCF0)
0000000000000040:find_item_in_tree:(FFFFFA8302259180, FFFFF8A001B11640, FFFFF880039FBD20, FFFFF880039FBCF0, 0)
0000000000000040:get_xattr:could not find item (100,18,914f9939)
0000000000000040:_find_item:(FFFFFA8302259180, FFFFF8A0017E34C0, FFFFF880039FBD98, FFFFF880039FBD60)
0000000000000040:_load_tree:(FFFFFA8302259180, 420000)
0000000000000040:_load_tree:returning FFFFF8A00153E290
0000000000000040:find_item_in_tree:(FFFFFA8302259180, FFFFF8A00153E290, FFFFF880039FBD98, FFFFF880039FBD60, 0)
0000000000000040:mount_vol:mount_vol done (status: 0)
0000000000000040:drv_create:create (flags = 884)
0000000000000040:drv_create:flags:
0000000000000040:drv_create:SL_STOP_ON_SYMLINK
0000000000000040:drv_create:file name: \System Volume Information\MountPointManagerRemoteDatabase
0000000000000040:drv_create:getting tree_lock 0->1
0000000000000040:debug_create_options:requested options:
0000000000000040:debug_create_options:    FILE_SYNCHRONOUS_IO_NONALERT
0000000000000040:debug_create_options:    FILE_NON_DIRECTORY_FILE
0000000000000040:open_file:requested disposition: FILE_OPEN
0000000000000040:open_file:(\System Volume Information\MountPointManagerRemoteDatabase)
0000000000000040:open_file:FileObject = FFFFFA830422F530
0000000000000040:open_fileref:(FFFFFA8302259180, FFFFF880039FBF38, 0000000000000000, 0, FFFFF880039FBEF8)
0000000000000040:find_file_in_dir:System Volume Information
0000000000000040:find_file_in_dir:crc32c(System Volume Information) = fdf4155f
0000000000000040:find_file_in_dir_with_crc32:(FFFFFA8302259180, System Volume Information, fdf4155f, FFFFF8A0011D3DE0, 100, FFFFF880039FBDD8, FFFFF880039FBDE8, FFFFF880039FBDE0)
0000000000000040:_find_item:(FFFFFA8302259180, FFFFF8A0011D3DE0, FFFFF880039FBBA0, FFFFF880039FBB50)
0000000000000040:find_item_in_tree:(FFFFFA8302259180, FFFFF8A001B11640, FFFFF880039FBBA0, FFFFF880039FBB50, 0)
0000000000000040:find_file_in_dir_with_crc32:found item 100,c,100
0000000000000040:_find_item:(FFFFFA8302259180, FFFFF8A0011D3DE0, FFFFF880039FBB88, FFFFF880039FBB50)
0000000000000040:find_item_in_tree:(FFFFFA8302259180, FFFFF8A001B11640, FFFFF880039FBB88, FFFFF880039FBB50, 0)
0000000000000040:find_file_in_dir_with_crc32:found item 100,c,100
0000000000000040:open_fileref:could not find System Volume Information
0000000000000040:open_fileref:returning c000003a
0000000000000040:open_file:open_fileref returned c000003a
0000000000000040:drv_create:releasing tree_lock 1->0
0000000000000040:drv_create:create returning c000003a
0000000000000040:drv_create:create (flags = 884)
0000000000000040:drv_create:flags: (none)
0000000000000040:drv_create:file name: \$Extend\$Reparse:$R:$INDEX_ALLOCATION
0000000000000040:drv_create:getting tree_lock 0->1
0000000000000040:debug_create_options:requested options:
0000000000000040:debug_create_options:    FILE_SYNCHRONOUS_IO_NONALERT
0000000000000040:open_file:requested disposition: FILE_OPEN
0000000000000040:open_file:(\$Extend\$Reparse:$R:$INDEX_ALLOCATION)
0000000000000040:open_file:FileObject = FFFFFA830422F530
0000000000000040:open_fileref:(FFFFFA8302259180, FFFFF880039FBE48, 0000000000000000, 0, FFFFF880039FBE08)
0000000000000040:find_file_in_dir:$Extend
0000000000000040:find_file_in_dir:crc32c($Extend) = a06478f2
0000000000000040:find_file_in_dir_with_crc32:(FFFFFA8302259180, $Extend, a06478f2, FFFFF8A0011D3DE0, 100, FFFFF880039FBCE8, FFFFF880039FBCF8, FFFFF880039FBCF0)
0000000000000040:_find_item:(FFFFFA8302259180, FFFFF8A0011D3DE0, FFFFF880039FBAB0, FFFFF880039FBA60)
0000000000000040:find_item_in_tree:(FFFFFA8302259180, FFFFF8A001B11640, FFFFF880039FBAB0, FFFFF880039FBA60, 0)
0000000000000040:find_file_in_dir_with_crc32:found item 100,c,100
0000000000000040:_find_item:(FFFFFA8302259180, FFFFF8A0011D3DE0, FFFFF880039FBA98, FFFFF880039FBA60)
0000000000000040:find_item_in_tree:(FFFFFA8302259180, FFFFF8A001B11640, FFFFF880039FBA98, FFFFF880039FBA60, 0)
0000000000000040:find_file_in_dir_with_crc32:found item 100,c,100
0000000000000040:open_fileref:could not find $Extend
0000000000000040:open_fileref:returning c000003a
0000000000000040:open_file:open_fileref returned c000003a
0000000000000040:drv_create:releasing tree_lock 1->0
0000000000000040:drv_create:create returning c000003a
0000000000000700:drv_create:create (flags = 884)
0000000000000700:drv_create:flags: (none)
0000000000000700:drv_create:file name: \test
0000000000000700:drv_create:getting tree_lock (exclusive) 0->1
0000000000000700:drv_create:open tree count = 5
0000000000000700:debug_create_options:requested options:
0000000000000700:debug_create_options:    FILE_SYNCHRONOUS_IO_NONALERT
0000000000000700:debug_create_options:    FILE_NON_DIRECTORY_FILE
0000000000000700:debug_create_options:    FILE_DISALLOW_EXCLUSIVE
0000000000000700:open_file:requested disposition: FILE_CREATE
0000000000000700:open_file:(\test)
0000000000000700:open_file:FileObject = FFFFFA83047B7070
0000000000000700:open_fileref:(FFFFFA8302259180, FFFFF880043D92C8, 0000000000000000, 0, FFFFF880043D9288)
0000000000000700:find_file_in_dir:test
0000000000000700:find_file_in_dir:crc32c(test) = a41a2787
0000000000000700:find_file_in_dir_with_crc32:(FFFFFA8302259180, test, a41a2787, FFFFF8A0011D3DE0, 100, FFFFF880043D9168, FFFFF880043D9178, FFFFF880043D9170)
0000000000000700:_find_item:(FFFFFA8302259180, FFFFF8A0011D3DE0, FFFFF880043D8F30, FFFFF880043D8EE0)
0000000000000700:find_item_in_tree:(FFFFFA8302259180, FFFFF8A001B11640, FFFFF880043D8F30, FFFFF880043D8EE0, 0)
0000000000000700:find_file_in_dir_with_crc32:found item 100,c,100
0000000000000700:_find_item:(FFFFFA8302259180, FFFFF8A0011D3DE0, FFFFF880043D8F18, FFFFF880043D8EE0)
0000000000000700:find_item_in_tree:(FFFFFA8302259180, FFFFF8A001B11640, FFFFF880043D8F18, FFFFF880043D8EE0, 0)
0000000000000700:find_file_in_dir_with_crc32:found item 100,c,100
0000000000000700:open_fileref:could not find test
0000000000000700:open_fileref:returning c0000034
0000000000000700:file_create:(FFFFFA8303CA2AB0, FFFFFA8302259180, FFFFFA83047B7070, \test, 2, 20060)
0000000000000700:open_fileref:(FFFFFA8302259180, FFFFF880043D90B0, 0000000000000000, 1, 0000000000000000)
0000000000000700:open_fileref:returning 00000000
0000000000000700:_find_item:(FFFFFA8302259180, FFFFF8A0011D3DE0, FFFFF880043D8DE8, FFFFF880043D8DB0)
0000000000000700:find_item_in_tree:(FFFFFA8302259180, FFFFF8A001B11640, FFFFF880043D8DE8, FFFFF880043D8DB0, 0)
0000000000000700:file_create2:filename = test, crc = a41a2787, dirpos = 2
0000000000000700:_find_item:(FFFFFA8302259180, FFFFF8A0011D3DE0, FFFFF880043D8F20, FFFFF880043D8E70)
0000000000000700:find_item_in_tree:(FFFFFA8302259180, FFFFF8A001B11640, FFFFF880043D8F20, FFFFF880043D8E70, 0)
0000000000000700:delete_tree_item:deleting item 100,1,0 (ignore = FALSE)
0000000000000700:insert_tree_item:(FFFFFA8302259180, FFFFF8A0011D3DE0, 100, 1, 0, FFFFF8A0018A4360, a0, 0000000000000000, FFFFF880043D9438)
0000000000000700:_find_item:(FFFFFA8302259180, FFFFF8A0011D3DE0, FFFFF880043D8DA0, FFFFF880043D8D38)
0000000000000700:find_item_in_tree:(FFFFFA8302259180, FFFFF8A001B11640, FFFFF880043D8DA0, FFFFF880043D8D38, 1)
0000000000000700:insert_tree_item:tp.item = FFFFF8A001834220
0000000000000700:insert_tree_item:tp.item->key = FFFFF8A001834220
0000000000000700:insert_tree_item:inserting 100,1,0 into tree beginning 100,1,0 (num_items 1)
0000000000000700:_find_item:(FFFFFA8302259180, FFFFF8A0011D3DE0, FFFFF880043D8DE0, FFFFF880043D8DB0)
0000000000000700:find_item_in_tree:(FFFFFA8302259180, FFFFF8A001B11640, FFFFF880043D8DE0, FFFFF880043D8DB0, 0)
0000000000000700:get_last_inode:moving on to 100,1,0
0000000000000700:get_last_inode:last inode for tree 5 is 100
0000000000000700:insert_tree_item:(FFFFFA8302259180, FFFFF8A0011D3DE0, 100, 60, 2, FFFFF8A001848010, 22, 0000000000000000, FFFFF880043D9438)
0000000000000700:_find_item:(FFFFFA8302259180, FFFFF8A0011D3DE0, FFFFF880043D8DA0, FFFFF880043D8D38)
0000000000000700:find_item_in_tree:(FFFFFA8302259180, FFFFF8A001B11640, FFFFF880043D8DA0, FFFFF880043D8D38, 1)
0000000000000700:insert_tree_item:tp.item = FFFFF8A001861D40
0000000000000700:insert_tree_item:tp.item->key = FFFFF8A001861D40
0000000000000700:insert_tree_item:inserting 100,60,2 into tree beginning 100,1,0 (num_items 2)
0000000000000700:_find_item:(FFFFFA8302259180, FFFFF8A0011D3DE0, FFFFF880043D8DE8, FFFFF880043D8DC0)
0000000000000700:find_item_in_tree:(FFFFFA8302259180, FFFFF8A001B11640, FFFFF880043D8DE8, FFFFF880043D8DC0, 0)
0000000000000700:insert_tree_item:(FFFFFA8302259180, FFFFF8A0011D3DE0, 100, 54, a41a2787, FFFFF8A001848070, 22, 0000000000000000, FFFFF880043D9438)
0000000000000700:_find_item:(FFFFFA8302259180, FFFFF8A0011D3DE0, FFFFF880043D8CF0, FFFFF880043D8C88)
0000000000000700:find_item_in_tree:(FFFFFA8302259180, FFFFF8A001B11640, FFFFF880043D8CF0, FFFFF880043D8C88, 1)
0000000000000700:insert_tree_item:tp.item = FFFFF8A001861D40
0000000000000700:insert_tree_item:tp.item->key = FFFFF8A001861D40
0000000000000700:insert_tree_item:inserting 100,54,a41a2787 into tree beginning 100,1,0 (num_items 3)
0000000000000700:_find_item:(FFFFFA8302259180, FFFFF8A0011D3DE0, FFFFF880043D8DC8, FFFFF880043D8DA0)
0000000000000700:find_item_in_tree:(FFFFFA8302259180, FFFFF8A001B11640, FFFFF880043D8DC8, FFFFF880043D8DA0, 0)
0000000000000700:insert_tree_item:(FFFFFA8302259180, FFFFF8A0011D3DE0, 101, c, 100, FFFFF8A001619C00, e, 0000000000000000, FFFFF880043D9438)
0000000000000700:_find_item:(FFFFFA8302259180, FFFFF8A0011D3DE0, FFFFF880043D8CD0, FFFFF880043D8C68)
0000000000000700:find_item_in_tree:(FFFFFA8302259180, FFFFF8A001B11640, FFFFF880043D8CD0, FFFFF880043D8C68, 1)
0000000000000700:insert_tree_item:tp.item = FFFFF8A0018A66A0
0000000000000700:insert_tree_item:tp.item->key = FFFFF8A0018A66A0
0000000000000700:insert_tree_item:inserting 101,c,100 into tree beginning 100,1,0 (num_items 4)
0000000000000700:file_create2:requested attributes = 80
0000000000000700:file_create2:defda = 0
0000000000000700:set_xattr:(FFFFFA8302259180, 5, 101, user.DOSATTRIB, 914f9939, FFFFF880043D8F30, 4)
0000000000000700:_find_item:(FFFFFA8302259180, FFFFF8A0011D3DE0, FFFFF880043D8DC8, FFFFF880043D8DA0)
0000000000000700:find_item_in_tree:(FFFFFA8302259180, FFFFF8A001B11640, FFFFF880043D8DC8, FFFFF880043D8DA0, 0)
0000000000000700:insert_tree_item:(FFFFFA8302259180, FFFFF8A0011D3DE0, 101, 18, 914f9939, FFFFF8A00072DFD0, 30, 0000000000000000, FFFFF880043D9438)
0000000000000700:_find_item:(FFFFFA8302259180, FFFFF8A0011D3DE0, FFFFF880043D8CD0, FFFFF880043D8C68)
0000000000000700:find_item_in_tree:(FFFFFA8302259180, FFFFF8A001B11640, FFFFF880043D8CD0, FFFFF880043D8C68, 1)
0000000000000700:insert_tree_item:tp.item = FFFFF8A0020DB770
0000000000000700:insert_tree_item:tp.item->key = FFFFF8A0020DB770
0000000000000700:insert_tree_item:inserting 101,18,914f9939 into tree beginning 100,1,0 (num_items 5)
0000000000000700:set_xattr:(FFFFFA8302259180, 5, 101, security.NTACL, 45922146, FFFFF8A0015F0980, 144)
0000000000000700:_find_item:(FFFFFA8302259180, FFFFF8A0011D3DE0, FFFFF880043D8DC8, FFFFF880043D8DA0)
0000000000000700:find_item_in_tree:(FFFFFA8302259180, FFFFF8A001B11640, FFFFF880043D8DC8, FFFFF880043D8DA0, 0)
0000000000000700:insert_tree_item:(FFFFFA8302259180, FFFFF8A0011D3DE0, 101, 18, 45922146, FFFFF8A0011BB660, bc, 0000000000000000, FFFFF880043D9438)
0000000000000700:_find_item:(FFFFFA8302259180, FFFFF8A0011D3DE0, FFFFF880043D8CD0, FFFFF880043D8C68)
0000000000000700:find_item_in_tree:(FFFFFA8302259180, FFFFF8A001B11640, FFFFF880043D8CD0, FFFFF880043D8C68, 1)
0000000000000700:insert_tree_item:tp.item = FFFFF8A0020DB770
0000000000000700:insert_tree_item:tp.item->key = FFFFF8A0020DB770
0000000000000700:insert_tree_item:inserting 101,18,45922146 into tree beginning 100,1,0 (num_items 6)
0000000000000700:insert_tree_item:(FFFFFA8302259180, FFFFF8A0011D3DE0, 101, 1, 0, FFFFF8A001835690, a0, 0000000000000000, FFFFF880043D9438)
0000000000000700:_find_item:(FFFFFA8302259180, FFFFF8A0011D3DE0, FFFFF880043D8DA0, FFFFF880043D8D38)
0000000000000700:find_item_in_tree:(FFFFFA8302259180, FFFFF8A001B11640, FFFFF880043D8DA0, FFFFF880043D8D38, 1)
0000000000000700:insert_tree_item:tp.item = FFFFF8A0018A66A0
0000000000000700:insert_tree_item:tp.item->key = FFFFF8A0018A66A0
0000000000000700:insert_tree_item:inserting 101,1,0 into tree beginning 100,1,0 (num_items 7)
0000000000000700:file_create2:created new file \test in subvol 5, inode 101
0000000000000700:drv_create:releasing tree_lock 1->0
0000000000000700:drv_create:open tree count = 5
0000000000000700:drv_create:create returning 00000000
0000000000000700:drv_query_information:query information
0000000000000700:drv_query_information:getting tree_lock 0->1
0000000000000700:drv_query_information:fcb = FFFFF8A002474680
0000000000000700:drv_query_information:fcb->subvol = FFFFF8A0011D3DE0
0000000000000700:query_info:(FFFFFA8302259180, FFFFFA83047B7070, FFFFFA830341DC60)
0000000000000700:query_info:fcb = FFFFF8A002474680
0000000000000700:query_info:FileStandardLinkInformation
0000000000000700:fill_in_file_standard_link_information:FileStandardLinkInformation
0000000000000700:query_info:query_info returning 00000000
0000000000000700:drv_query_information:returning 00000000
0000000000000700:drv_query_information:releasing tree_lock 1->0
0000000000000020:drv_create:create (flags = 884)
0000000000000020:drv_create:flags: (none)
0000000000000020:drv_create:open operation for volume
0000000000000020:drv_create:create returning 00000000
0000000000000020:drv_query_volume_information:query volume information
0000000000000020:drv_query_volume_information:FileFsVolumeInformation
0000000000000020:drv_query_volume_information:max length = 24
0000000000000020:drv_query_volume_information:getting tree_lock 0->1
0000000000000020:drv_query_volume_information:label_len = 0
0000000000000020:drv_query_volume_information:releasing tree_lock 1->0
0000000000000020:drv_query_volume_information:query volume information returning 00000000
0000000000000020:drv_cleanup:cleanup
0000000000000020:drv_cleanup:cleanup called for FileObject FFFFFA8303478BD0

I have an ordinary - but specific - file that causes a crash on Windows and a freeze on Linux. During the copy this file crashes at 434,8 MB of 725,3 MB with WinBtrfs from Windows and on Linux too.

This file is good, I can read it. Both Windows and Linux can read it and copying it without errors toward an ntfs partition.

On Windows I used WinBtrfs 0.7. I have Windows 8.1 32 bit and Debian testing with Xfce 32 bit. My HD is 298,1 GiB with 4 primary partitions.

I have to exclude an hard disk damage because I have tried 2 different hard disks and it rises up the same error.

Maybe WinBtrfs is innocent because the same error rises up on Linux. But this means that there is a very basilar bug.

This file is correctly copied from ntfs partition to another ntfs partition. Windows and Linux can do this correct copy, but when the file is copied from ntfs partition to btrfs partition Windows rises up a death screen and Linux freezes.

The copy is executed by usb and from internal partition to another internal partition. This doesn't make a difference.

Whether copying with Total Commander or Explorer, the copying process just stops and becomes non-responding.

Additional information:
It seems to happen at the end of copying a file, i.e. that some files are transferred without issue, but then all of a sudden the copying stops. I tested this with different files, so the source does not seem to be the problem.
The copying processes (either Total Commander or Explorer) are not killable ('access denied' in task manager). When trying to restart, the processes are noted as preventing restart. 'Restart anyway' continues but leads to a spinner spinning for at least 3 minutes (after which I performed a hard reset). If my knowledge of such behavior is correct, this is generally an indicator of the processes waiting for a kernel space component.

System information:
Winbtrfs 1.0
Windows 10 Pro
Build 15063.rs2_release.170317-1834
Volume is a ~2,9GB partition on a GPT drive, created with mkbtrfs.exe. The first partition on that drive is a 30GB Linux (swap) partition.

I will update this issue later with information from DebugView and the logs.

I noticed that editing (and saving) files with non-elevated privileges erases existing perms and ownership.
It sets the owner group to nobody and user according to the set mapping.
This doesn't happen with privileged editing and as we usually do edits in unprivileged programs like Sublime, it would be great if privileges and ownership data could be preserved.

Could you add a mapping for groups to the registry, too?

There is a patch made for linux that adds support for zstd, it improves compression without compromise performance. Is much better than zlib but faster as lzo.

Here is the patch

I know that your driver has nothing to do with the linux code, so I don't know if it's possible to port support for zstd, but since it's a great alternative for transparent compression I believe it's worth to try it out.

Are there plans to implement an BTRFS_IOC_CLONE ioctl equivalent on Windows?

I am asking, because if this is implemented I would be able to have UrBackup Server run on Windows with btrfs :)

In btrfs properties you can set a compression flag. I have a file and a folder compressed with zlib but want to change it to lzo, so I set it via the flag option, but it seems like it has no effect. I also ran a balancing.

Compressiontype is now set to 2 in registry (was 0 before)

Am I doing something wrong?

How much would it cost to submit executable for signing?

May be enough users can donate the necessary sum?

On Win7, I wanted to try out the btrfs driver without repartitioning. As it already worked with an ext3 volume, I tried a VHD again:

• Created a virtual disk (VHD) (it's dynamicly growing if it matters).
• Attach it.
• Disk manager shows volume with MBR but no partitions.

But how do I create a btrfs volume in it?

It's just a crazy thought: is it (or will it be) possible to boot Windows from btrfs partition using your driver since it's highly-integrated and tries to be seamless from the Windows' point of view?

The current approach only allows for one subvolume mount per UUID. It would be nice if it was somehow possible to mount more then one subvolume per UUID.
e.g. my btrfs partition (subvolid 5) with the following subvolumes:
/@root (default subvolume)
/@home

for me on linux
@root gets mounted to /
@home gets mounted to /home

it would be nice if it was possible on windows to either replicate this in similar fashion
e.g. @root to X:/ and @home to X:/home
or @root to X:/ and @home to Y:/

Currently I have to set subvolid 5 explicitly so i can access both subvolumes.

I've cloned the repo onto windows, enabled test mode, and right-clicked the .inf to install, but it prompts me for btrfs.sys, which is nowhere to be found. Am I missing something?

Hi!

First up, thanks for all the work you've done on this driver - it makes using BTRFS partitions on Windows a real breeze.

I've noticed that you track built versions of the driver in this repository - it is highly unrecommended to check in binary files into git.

I suggest that you use GitHub's releases feature to upload the prebuilt binaries - it will help keep the repository cleaner.

How do I uninstall the driver? It gives me bluescreens and I can't find any uninstall information.

A few days ago I've started to get BSODs IRQL_NOT_LESS_OR_EQUAL and SYSTEM_THREAD_EXCEPTION_NOT_HANDLED. If I remember correctly it started to happened after I upgraded to v0.10. I even got unbootable system and wasn't able to get it to live with the last restore point. At the end I've managed to get my system alive, but sometimes I'm still getting BSODs. WhoCrashed tells that the reason is btrfs.sys, but I can't be sure for 100% as I get problems with my Apple Magic Keyboard \ Magic Trackpad at the same time and it's pretty tough to make them work again. It can be some kind of incompatibility with Apple drivers and ExtraMagic Trackpad driver. I'm ready to send the latest crash dump but it's 1 GB length, so I'll send a link to it via email soon.

Would you like to add more error handling for return values from calls of a function like "ExAllocatePoolWithTag"?

I've gotten two new hard drives, and decided to give your Windows port of btrfs a try. It was working really well, up until a point I stored around 1.75TB on a 3TB drive. At this point Windows stopped letting me write anything to these drives, but data was still readable. If I try to transfer or copy anything to these drives, the action will be interrupted, and Windows will notify me that the Btrfs formatted disk is write-protected. To fix this, I open up diskpart, select the btrfs partition, and clear it's attributes, to apply this I also have to reboot the computer entirely, and then the drive seems to be writable for a few files or a few kilobytes (Can't tell because Steam always opens up and writes to it too quickly).

OS: Windows 10, Redstone 3

While I'm only storing games on this drive, the fact it stood up this long is impressive. Looking forward to seeing how this project evolves as I'd really like to use this daily on all of my drives.

It would be useful if the user mappings could be adjusted dynamically, without having to reload the driver/reboot.

For example, check the registry every n seconds for new entries (n=5? n=30? n configurable?)

Additionally, if the computer is in an Active Directory domain, it might be useful to pull the UNIX uid / gid for a specific user from there (and cache it locally for some time). I understand that this is not something that the driver itself should be doing, it probably needs a user-space companion that does the actual AD query and that replaces the uid on the file system as soon as they have been received from the AD

An btrfs volume created with the command:

mkfs -t btrfs /dev/sda1 (under a GPT filetable)

resulting in the following flags: big_metadata, extended_iref, mixed_backref, skinny_metadata from Arch Linux 4.6.2 x64 with btrfs-progs v4.6 cannot be read (no drive is displayed in explorer or mountvol) from my Microsoft Windows 10 x64 partition.

The drive is being detected in disk manager but does not indicate a partition type. A seperate USB memory stick loaded with btrfs under the same system can be loaded and interacted with with no problem. The drive also used to work (i.e. it was working at one point with btrfs) until one day detection failed (as such, I tried reformatting it to no avail). The drive is detectable when formatted with exFAT or NTFS in Windows.

Upon insertion, I've tried restarting explorer, starting explorer from a priveleged command prompt, mounting all the drives available in mountvol, refreshing explorer with F5 and removal and reinserting the drive.

The Arch Linux and the Windows system reside on the same hardware (dual boot) and the same USB slot was used (though I've tried different slots as well to no avail). The drive functions as intended in Arch. The drive has also been tested in another Microsoft Windows 10 x64 system with the same results (no drive detection).

Attached below is the btrfs kernel log as well as the debugview log, note that in the kernel log all events up to the last 0000000000000CC0 occurred prior to any btrfs volume was inserted to the system.

btrfs.txt
DebugView.txt

I can provide more information as necessary.

I'm on Windows 8.1 X64 build 9600. Test Mode is enabled. When I plug in my BTRFS drive, Windows tells me it's not initialized and wants to put a partition table on the drive. The drive mounts under Linux without issue. (It's an external USB 3.0 8TB drive. Single btrfs volume with LZO enabled. I've used this drive on the same windows computer, but formatted NTFS.)

I've tried both running loader.exe and installing with the inf and rebooting. I don't see the a service named 'btrfs' in Computer Management -> Services or Task Manager -> Services, however running loader.exe tells me the service already exists and is already running.

Thanks for any help. Can't wait to start using btrfs on Windows!

Can you reorganize the code a bit to move the lock initializations later in function, so that if mount_vol is called for non-btrfs volume, there is no need to release them.
Also if mount_vol is called for non-btrfs volume it returns STATUS_INTERNAL_ERROR from read_superblock instead of STATUS_UNRECOGNIZED_VOLUME.
Basically to implement cleanup for mount_vol if error occurs (it happens if called for non-btrfs volumes).
You should be able to hit this in windows if you present unrecognized volume (not fat, not ntfs, not udfs, etc) in the system when driver is loaded. Strange formatted (or unformatted) USB flash drive should do the trick I guess.

When the partition is Btrfs, Windows fails to move the Users folder to that partition. There is no issue when the partition is NTFS.

Tested with Windows 10 Pro (both 32 bit and 64 bit). I have not tried other versions of Windows.
The issue is present with both 0.5 and 0.6 Btrfs driver versions

Steps to reproduce the issue (works on both hardware and VM):
(based on http://www.tenforums.com/tutorials/1964-users-folder-move-location-windows-10-a.html )

1. Fresh install Windows 10
2. At the first install wizard:
   • Remove Windows install media
   • Insert Linux Live CD
   • hit Ctrl Shift F3 to enter Audit mode
3. When it restarts, boot into Linux Live CD
   • (To make things easier for multiple tests, you might want to shutdown the VM at this point and archive it so you can extract it and come back to this point later)
4. Create a new "shared" partition (Either NTFS or Btrfs)
5. Restart and continue into Audit mode
6. Enable Testing mode, restart
   • run as admin: bcdedit -set TESTSIGNING ON
7. Install Btrfs driver, restart
8. Still in audit mode, use sysprep with an unattend file to move C:\Users to (for example) F:\Users
   • run as admin:
   • %windir%\system32\sysprep\sysprep.exe /oobe /reboot /unattend:F:\relocate.xml
9. System restarts and comes back to the first install wizard

If at step 4 you created an NTFS partition, walking through the first install wizard ends with creating a new user account and works as it should.

If you created a Btrfs partition, it will not get to creating a new user. Instead, it will get stuck in a first wizard loop. A difference between 0.5 and 0.6: with 0.5 Windows does not successfully move all files to the Btrfs partition. Looks like with 0.6 it does successfully move everything.

Here's an example relocate.xml file to relocate the Users folder:

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
<settings pass="oobeSystem">
<component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<FolderLocations>
<ProfilesDirectory>F:\Users</ProfilesDirectory>
</FolderLocations>
</component>
</settings>
<cpi:offlineImage cpi:source="wim:E:\sources\install.wim#Windows 10 Pro" xmlns:cpi="urn:schemas-microsoft-com:cpi" />
</unattend>

There are 3 things you may need to change to reflect your setup:

• processorArchitecture="amd64" may need to be processorArchitecture="x86" if using 32bit
• <ProfilesDirectory>F:\Users</ProfilesDirectory> will need to have the drive letter of the target partition
• cpi:source="wim:E:\sources\install.wim#Windows 10 Pro"
  • The #Windows 10 Pro needs to be the correct edition
  • E:\sources\install.win path needs to point to an accessible install.wim file

Let me know if you need clarification on anything, or if there's anything I can do to help.

Version 0.8 on Windows 7 x64:

DUMP_CLASS: 1
DUMP_QUALIFIER: 0
BUILD_VERSION_STRING: 7601.18741.amd64fre.win7sp1_gdr.150202-1526
WRONG_SYMBOLS_TIMESTAMP: 54d0317d
WRONG_SYMBOLS_SIZE: 5e7000
FAULTING_MODULE: fffff8000285a000 nt
DEBUG_FLR_IMAGE_TIMESTAMP: 54d0317d
DUMP_TYPE: 0
BUGCHECK_P1: ffffffffc0000005
BUGCHECK_P2: fffff88002caf3e2
BUGCHECK_P3: fffff8800420d4f8
BUGCHECK_P4: fffff8800420cd50
EXCEPTION_CODE: (NTSTATUS) 0x54d0317d -
FAULTING_IP:
btrfs!update_tree_extents+602 [z:\home\hellas\desktop\wine\fs\btrfs\src\flushthread.c @ 793]
fffff880`02caf3e2 8b402c mov eax,dword ptr [rax+2Ch]

EXCEPTION_RECORD: fffff8800420d4f8 -- (.exr 0xfffff8800420d4f8)
ExceptionAddress: fffff88002caf3e2 (btrfs!update_tree_extents+0x0000000000000602)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000000
Parameter[1]: 000000000000002c
Attempt to read from address 000000000000002c

CONTEXT: fffff8800420cd50 -- (.cxr 0xfffff8800420cd50)
rax=0000000000000000 rbx=fffffa80056d2060 rcx=fffff8a010bf0b83
rdx=fffff8a010bf0b83 rsi=fffffa8003fd8450 rdi=0000000000000001
rip=fffff88002caf3e2 rsp=fffff8800420d730 rbp=0000000000000080
r8=fffff8800420d6b8 r9=0000000000000001 r10=fffffa8003f40148
r11=fffff8a010bf0aa0 r12=fffffa8006745050 r13=fffff88002cbd7a0
r14=0000000000000000 r15=fffff80000b94080
iopl=0 nv up ei pl nz na pe nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010202
btrfs!update_tree_extents+0x602:
fffff88002caf3e2 8b402c mov eax,dword ptr [rax+2Ch] ds:002b:000000000000002c=????????
Resetting default scope

CPU_COUNT: 2
CPU_MHZ: d4b
CPU_VENDOR: GenuineIntel
CPU_FAMILY: 6
CPU_MODEL: 3a
CPU_STEPPING: 9
CURRENT_IRQL: 0
ANALYSIS_SESSION_HOST: URPC
ANALYSIS_SESSION_TIME: 01-11-2017 13:26:30.0205
ANALYSIS_VERSION: 10.0.10586.567 amd64fre
LAST_CONTROL_TRANSFER: from fffff88002caecc6 to fffff88002caf3e2
STACK_TEXT:
fffff8800420d730 fffff88002caecc6 : fffffa80067451a0 fffff8a003605bd0 0000000000000000 fffff8800420db80 : btrfs!update_tree_extents+0x602 [z:\home\hellas\desktop\wine\fs\btrfs\src\flushthread.c @ 793]
fffff8800420d980 fffff88002cadb54 : fffffa80067451a0 0000000000000000 fffff8800420db80 fffff8800420db80 : btrfs!allocate_tree_extents+0x2f6 [z:\home\hellas\desktop\wine\fs\btrfs\src\flushthread.c @ 1116]
fffff8800420da00 fffff88002cbd93b : fffffa80067451a0 0000000000000000 fffff8800420db80 0000000000000001 : btrfs!do_write+0x764 [z:\home\hellas\desktop\wine\fs\btrfs\src\flushthread.c @ 5502]
fffff8800420db60 fffff88002cbd873 : fffffa80067451a0 fffffa8000000000 fffffa8000000000 fffff8800420dc00 : btrfs!do_flush+0x5b [z:\home\hellas\desktop\wine\fs\btrfs\src\flushthread.c @ 5662]
fffff8800420dba0 fffff80002b6db8a : fffffa8006745050 fffff80002a4be80 fffff8800420dc70 fffffa80056d2060 : btrfs!flush_thread+0xd3 [z:\home\hellas\desktop\wine\fs\btrfs\src\flushthread.c @ 5693]
fffff8800420dc00 fffff800028c08e6 : fffff80002a4be80 fffffa80056d2060 fffffa800401bb50 0000000000000000 : nt!PsCreateSystemThread+0x1da
fffff8800420dc40 0000000000000000 : fffff8800420e000 fffff88004208000 fffff8800420cca0 0000000000000000 : nt!KeInitializeSemaphore+0x25a
THREAD_SHA1_HASH_MOD_FUNC: 0bd7c172bee0e06aa4acb424ebc1375d875c8368
THREAD_SHA1_HASH_MOD_FUNC_OFFSET: 434b67b48b834ff5a6464515b05028d3f918ce26
THREAD_SHA1_HASH_MOD: d8536f19397b300fcb041d1189453fb65a43a6b1
FOLLOWUP_IP:
btrfs!update_tree_extents+602 [z:\home\hellas\desktop\wine\fs\btrfs\src\flushthread.c @ 793]
fffff880`02caf3e2 8b402c mov eax,dword ptr [rax+2Ch]
FAULT_INSTR_CODE: 892c408b
FAULTING_SOURCE_LINE: z:\home\hellas\desktop\wine\fs\btrfs\src\flushthread.c
FAULTING_SOURCE_FILE: z:\home\hellas\desktop\wine\fs\btrfs\src\flushthread.c
FAULTING_SOURCE_LINE_NUMBER: 793
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: nt_wrong_symbols!54D0317D5E7000
FOLLOWUP_NAME: MachineOwner
STACK_COMMAND: .cxr 0xfffff8800420cd50 ; kb
BUGCHECK_STR: 54D0317D
EXCEPTION_CODE_STR: 54D0317D
FAILURE_EXCEPTION_CODE: 54D0317D
EXCEPTION_STR: WRONG_SYMBOLS
PROCESS_NAME: ntoskrnl.wrong.symbols.exe
IMAGE_NAME: ntoskrnl.wrong.symbols.exe
MODULE_NAME: nt_wrong_symbols
BUCKET_ID: WRONG_SYMBOLS_X64_7601.18741.amd64fre.win7sp1_gdr.150202-1526_TIMESTAMP_150203-022501
DEFAULT_BUCKET_ID: WRONG_SYMBOLS_X64_7601.18741.amd64fre.win7sp1_gdr.150202-1526_TIMESTAMP_150203-022501
PRIMARY_PROBLEM_CLASS: WRONG_SYMBOLS
FAILURE_BUCKET_ID: WRONG_SYMBOLS_X64_7601.18741.amd64fre.win7sp1_gdr.150202-1526_TIMESTAMP_150203-022501_54D0317D_nt_wrong_symbols!54D0317D5E7000
TARGET_TIME: 2017-01-11T12:26:00.000Z
OSBUILD: 7601
OSSERVICEPACK: 1000
SERVICEPACK_NUMBER: 0
OS_REVISION: 0
SUITE_MASK: 272
PRODUCT_TYPE: 1
OSPLATFORM_TYPE: x64
OSNAME: Windows 7
OSEDITION: Windows 7 WinNt (Service Pack 1) TerminalServer SingleUserTS
OS_LOCALE:
USER_LCID: 0
OSBUILD_TIMESTAMP: 2015-02-03 03:25:01
BUILDDATESTAMP_STR: 150202-1526
BUILDLAB_STR: win7sp1_gdr
BUILDOSVER_STR: 6.1.7601.18741.amd64fre.win7sp1_gdr.150202-1526
ANALYSIS_SESSION_ELAPSED_TIME: 3c
ANALYSIS_SOURCE: KM
FAILURE_ID_HASH_STRING: km:wrong_symbols_x64_7601.18741.amd64fre.win7sp1_gdr.150202-1526_timestamp_150203-022501_54d0317d_nt_wrong_symbols!54d0317d5e7000
FAILURE_ID_HASH: {c3603831-0fe3-e90c-bda5-7cc3bb41a047}
Followup: MachineOwner

Hello!

I'm trying to use WinBtrfs with Windows 10 Home, build 14393.-.170327-1835. While it seems to work perfectly within Explorer, I can't get access to the partition from WSL. Every time I'm trying to cd into /mnt/d/root I get "Permission denied". I've tried to run bash as Administrator, I've tried to sudo -i first: it doesn't help.
BTRFS partition is a partition on the same drive, the root partition of the installed Fedora Linux.

Did I miss something, could you please point me to the right direction?

Thanks!

It seems that I was overconfident when told before that in normal mode (in Explorer) everything works perfectly.

Don't know how to explain it, but I can create\copy\edit files with size less than around 58MB. If I'm trying to copy a bigger file to a btrfs partition I get message "You need XXX MB to copy this object. Delete or move files to free space". And actual amount of needed space varies depending on the file size (I mean, it can ask for 77MB more if file size is 77MB and for 686MB if file size is 707MB or 702MB).

I know nothing about btrfs internals and its windows implementation but I would suppose that the biggest free space block on my btrfs partition is around 58MB and FS driver can't split data into chunks. But it's a shot in the dark. :)

WinBtrfs 0.9 with Windows 10 Home, build 14393.-.170327-1835

Hi,

when I install the driver and reboot, all btrfs partitions are mounted read/write by default. As far as I am aware, the only way to prevent this is to either

1. know the subkey of HKLM\SYSTEM\CurrentControlSet\Services\btrfs corresponding to my partition and set HKLM\SYSTEM\CurrentControlSet\Services\btrfs\<SUBKEY>\Readonly to 1 prior to activating the driver, or
2. alter the source code of the driver.

Arguably, making read/write access opt-in rather than opt-out makes for a more sensible default:

1. Windows creates the /$RECYCLE.BIN and /System Volume Information directories at all the mounted partitions. You generally don't want these in the root directory of your linux btrfs partitions.
2. After a test boot with the driver installed, I found that my root btrfs filesystem was corrupted (all safely backed up) to the point where it would not mount on linux 4.9.30 given the following /etc/fstab line

/dev/sdXY / btrfs discard,relatime,compress 0 0

without running btrfs check --repair /dev/sdXY first. Attached is the output of btrfs check:

$ btrfs --version
btrfs-progs v4.12
$ btrfs check sdXY.img
Checking filesystem on sdXY.img
UUID: 0c71059e-c962-4709-8db9-664684cca639
checking extents
checksum verify failed on 25861799936 found E4E3BDB6 wanted 00000000
checksum verify failed on 25861799936 found E4E3BDB6 wanted 00000000
bytenr mismatch, want=25861799936, have=0
ERROR: errors found in extent allocation tree or chunk allocation
root item for root 511, current bytenr 25861799936, current gen 323909, current level 2, new bytenr 25925255168, new gen 323915, new level 2
Found 1 roots with an outdated root item.
Please run a filesystem check with the option --repair to fix them.

I can provide parts of the image should you wish to investigate further.

For the above reasons, I suggest the driver should create HKLM\SYSTEM\CurrentControlSet\Services\btrfs\<SUBKEY>\Readonly with the value of 1 for all the new btrfs partitions it detects and that read/write access should become opt-in rather than opt-out.

For starting users, it would be helpfull to note that the windows user ID can be found using:
wmic useraccount get name,sid

For Windows 10, it would be helpfull to have documentation on how to self-sign drivers:

Get New-SelfSignedCertificateEx.ps1

Run Powershell as administrator:

Set-ExecutionPolicy Unrestricted
Import-Module .\New-SelfSignedCertificateEx.ps1
$pw = convertto-securestring "secret" -asplaintext -force
New-SelfsignedCertificateEx -Subject "CN=Test Root CA2, OU=Sandbox" -IsCA $true -ProviderName "Microsoft Software Key Storage Provider" -Exportable -Path ssl.pfx -Password $pw -NotAfter $([datetime]::now.AddYears(50))

Install the certificate using right-click
Install the windows SDK
the start a command prompt in the cloned btrfs acrhive:

"C:\Program Files (x86)\Windows Kits\10\bin\x86\Inf2Cat.exe" /drv:. /os:7_X64,10_X64 /v
"C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x64\signtool.exe" sign /v /f ssl.pfx /p secret /t http://timestamp.comodoca.com/authenticode btrfs.cat
bcdedit /set testsigning on

Right-click on the btrfs.inf to install the driver.

v1.0.1 with lzo compression enabled.
After writing a file (via LXSS) with dd (or other bigger files) the Volume becomes unaccessible / unavailable. It says F:\ path not found ... bcs another process is using it.

Everything is ok after rebooting.

Debug (level 2) Log:

Starting logging at 2017-11-03 01:17:04
FFFFBD808888A700:fsctl_request:STUB: FSCTL_GET_NTFS_VOLUME_DATA
FFFFBD808633C080:fsctl_request:unknown control code 94264 (DeviceType = 9, Access = 1, Function = 99, Method = 0)
FFFFBD808B792700:fsctl_request:STUB: FSCTL_REQUEST_OPLOCK
FFFFBD808B792700:fsctl_request:STUB: FSCTL_REQUEST_OPLOCK
FFFFBD808C6B0080:fsctl_request:STUB: FSCTL_REQUEST_OPLOCK
FFFFBD808C6B0080:fsctl_request:STUB: FSCTL_REQUEST_OPLOCK
FFFFBD808C6B0080:fsctl_request:STUB: FSCTL_REQUEST_OPLOCK
FFFFBD808C6B0080:fsctl_request:STUB: FSCTL_REQUEST_OPLOCK
FFFFBD808C6B0080:fsctl_request:STUB: FSCTL_REQUEST_OPLOCK
FFFFBD808C6B0080:fsctl_request:STUB: FSCTL_REQUEST_OPLOCK
FFFFBD808C6B0080:fsctl_request:STUB: FSCTL_REQUEST_OPLOCK
FFFFBD808C6B0080:fsctl_request:STUB: FSCTL_REQUEST_OPLOCK
FFFFBD808C6B0080:fsctl_request:STUB: FSCTL_REQUEST_OPLOCK
FFFFBD808C6B0080:fsctl_request:STUB: FSCTL_REQUEST_OPLOCK
FFFFBD808C419700:fsctl_request:STUB: FSCTL_REQUEST_OPLOCK
FFFFBD808C2AB040:fsctl_request:STUB: FSCTL_REQUEST_OPLOCK
FFFFBD808C2AB040:fsctl_request:STUB: FSCTL_REQUEST_OPLOCK
FFFFBD808C2AB040:fsctl_request:STUB: FSCTL_REQUEST_OPLOCK
FFFFBD808C2AB040:fsctl_request:STUB: FSCTL_REQUEST_OPLOCK
FFFFBD808C2AB040:fsctl_request:STUB: FSCTL_REQUEST_OPLOCK
FFFFBD808C6CD080:fsctl_request:STUB: FSCTL_REQUEST_OPLOCK
FFFFBD808C6CD080:fsctl_request:STUB: FSCTL_REQUEST_OPLOCK
FFFFBD8087505700:query_info:unknown FileInformationClass 68

Hi,

is it possible, or is intended to become possible to have WinBtrfs use a partition, which is encrypted by a typical corporate disk encryption solution like PGP Desktop, or McAffee Disk Encryption?

Thanks,

Jochen

I couldn't find any benchmarks or any information about the performance of WinBtrfs, so I made a quick test with CrystalDiskMark 5. It seems that winbtrfs has better random writes/reads but lower seq. write/read performance.

Have you made similar observations?

OS : Windows 10 Professional [10.0 Build 16299] (x64)
WinBtrfs v1.0.1 on HDD

WinBTRFS with LZO
Sequential Read (Q= 32,T= 1) : 119.619 MB/s
Sequential Write (Q= 32,T= 1) : 93.616 MB/s
Random Read 4KiB (Q= 32,T= 1) : 1.381 MB/s [ 337.2 IOPS]
Random Write 4KiB (Q= 32,T= 1) : 1.874 MB/s [ 457.5 IOPS]
Sequential Read (T= 1) : 117.870 MB/s
Sequential Write (T= 1) : 122.909 MB/s
Random Read 4KiB (Q= 1,T= 1) : 0.672 MB/s [ 164.1 IOPS]
Random Write 4KiB (Q= 1,T= 1) : 4.304 MB/s [ 1050.8 IOPS]

NTFS
Sequential Read (Q= 32,T= 1) : 152.757 MB/s
Sequential Write (Q= 32,T= 1) : 145.346 MB/s
Random Read 4KiB (Q= 32,T= 1) : 0.951 MB/s [ 232.2 IOPS]
Random Write 4KiB (Q= 32,T= 1) : 1.098 MB/s [ 268.1 IOPS]
Sequential Read (T= 1) : 154.369 MB/s
Sequential Write (T= 1) : 146.380 MB/s
Random Read 4KiB (Q= 1,T= 1) : 0.395 MB/s [ 96.4 IOPS]
Random Write 4KiB (Q= 1,T= 1) : 1.153 MB/s [ 281.5 IOPS]

I managed to get this driver working for short periods of time using the loader.exe method but after trying to change permissions of files or loading disk management, or trying to use NexusModManager on the drive resulted in hard locking of the system.

The INF driver prevents windows from booting in any mode regardless of settings. This is a rather annoying issue because it even prevents error reporting due to the system wide lock up so I don't know what else to provide other then 'its broken'.

But thanks for making a driver non the less, perhaps if we can figure out why this hard lock happens it would be great, I even managed to get a game running off the drive but not for long.

After messing with x86 PAE patch (from wj32.org) and other lame "bcdedit /set pae ForceEnabled" stuff; getting "An internal error occured." message while selecting the drive within File Explorer.

// It happens after removing the PAE boot entry from within msconfig utility and reinstalling *.inf as well.

Driver status in Device Manager >>> Storage volumes says it's working properly.

Any hints much appreciated.

Would you like to replace more defines for constant values by enumerations to stress their relationships?

After running the v1.0 install inf file (While still having the old one installed) I tried to open my btrfs volume, but I was met with a bluescreen. After trying to uninstall the old one and also trying to install the new one again, I think I just broke everything. I disabled and removed the btrfs key in regedit, deleted the btrfs file in C:/Windows. Now when I try to install the 1.0 inf file I get an error saying installation failed and then a pop-up saying operation completed successfully but even then my btrfs partition doesn't open. Any advice on how I fucked up would be appreciated.

Sorry if this is the wrong forum to ask questions, but I couldn't find anything else.

• Is there a way to force it to mount readonly?
• If the answer is yes, would that make it less likely to get corrupted?

I just need read-only access to my storage from windows for the most part.

I have a svn (subversion) directory on my btrfs. I just tried to update that folder through windows. And I received an instant BSOD crash.

From the event log:
The computer has rebooted from a bugcheck. The bugcheck was: 0x0000003b (0x00000000c0000005, 0xfffff800f1819d34, 0xffffd001fdcdad10, 0x0000000000000000). A dump was saved in: C:\WINDOWS\MEMORY.DMP. Report Id: ebee2170-776d-4fac-9304-e3b36e6f2494.

Windows 10 Pro 64-bit 1709
Intel Core i7 4770K
Gigabyte Technology Co. Ltd. Z97X-Gaming GT

Kingston DTIG4/32GB DataTraveler

Put file in btrfs pen drive get a blue screen.
Remove btrfs pen drive cause a different blue screen.
Unable to create btrfs file system with format and also with mkbtrfs (FormatEx failed).

Last night I have tried to browse the code a little bit. Since the code base is quite large, I just scanned seveal routines, especially the DriverEntry, and would like to point to the problems.

• In general, your DriverEntry does not perform any cleanup when it fails. You really should do that. Unlike in the usermode world, nobody cleans a mess (i.e. allocated memory, threads) after unloaded drivers. Well, there are probably some exceptions but I think it is a good habit not to rely on them too much. For example, when you call ExInitializeResourceLite you should also invoke the opposite (ExDeleteResourceLite) before your driver unloads (that includes a failure in the DriverEntry). Executive resources are linked into a list, so their state may be tracked by some WinDbg commands, such as !locks, that may be helpful when identifying deadlocks. So, if you do not delete the e. resource and unload your driver, its, now non-existent, memory remains in the list, so you get a BSOD when somebody touches it. Similar considerations apply to threads, timers, DPCs and other objects.

• ExInitializeResourceLite may fail and you should check for that and take appropriate actions if such a thing happens. A general rule is that when a routine returns a NTSTATUS code, it may fail.

• I have a good experience with wrapping memory allocation routines (ExAllocatePoolXxx) into my own memory allocator that tracks memory leaks and origins of individual allocations. AFAIK the kernel implements no such thing by itself. Similarly, I discovered that making wrappers for locking primitives has also its benefits, at leat for checking that the code runs on right IRQL. For example, acquiring an executive resource (ExAcquireResourceXxxLite) on DISPATCH_LEVEL does not crash the system if there is no need to block the caller, however, may have some terrible consequences later, masking the original cause of the problem.

Windows 10 v1703 x64
btrfs volume was created with mkbtrfs.exe without options.

Create a subvolume and create a subvolume in previous subvolume.

\  
└───New subvolume  
    └───New subvolume  

Create a snapshot of the upper subvolume in the above state.

\
├───New subvolume
│   └───New subvolume
└───Snapshot of New subvolume (2017-04-06)
    └───New subvolume

Delete snapshot, then crash.
Sometimes it does not crash, but at that time the lower subvolume disappears.

Log file(DebugLogLevel=3) of v0.9 btrfs1.txt
This log file is the one when crashed with the binary I built from source code at 7c208a4. btrfs2.txt

There is no mention of groups mappings, only user mapping.
If groups mappings are supported, please update readme, if not, please consider this as a feature suggestion.

Hey, have you considered implementing the driver in userspace using Dokan? It provides both its own callback API and FUSE API. It might make the development easier (or not, I can't make a qualified guess here).

https://github.com/dokan-dev/dokany

Forgive me if this is a stupid question, but the readme file says that to just run the driver, I should run loader.exe, but the latest release (0.10) doesn't include a loader.exe. Do I need to build the driver?

Also, right-clicking the inf file and clicking "install" doesn't seem to work either. It copies a file, but when I reboot, the btrfs partition isn't showing up.

Btrfs version: v1.0.1
OS: win7 x64
Security Software: Commodo Firewall 10, ESET NOD32 v4.2.76.1, GlassWire Lite v1.2.118
Partition: 2nd main partition on a USB harddisk

I tried the following commands, they both said: FormatEx failed

format /fs:btrfs s:

and

mkbtrfs s: