Windows doesn't give err infomation when clearing a file without truncate right

[Lucasq11]

Environment

• Windows version: Windows10 professional
• Processor architecture: x64
• Dokany version: 1.4.0.1000
• Library type (Dokany/FUSE): Dokany

Check List

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

Description

I want to disable truncate operation for some specific files, and SetEndOfFile returned c0000022 like what I expected, but windows still don't know that this file shouldn't be cleared and give no report. How should I get a report windows after truncate operation is failed?

Logs

###Create 0095
CreateFile: \A\test_file.txt
    DesiredAccess: FILE_GENERIC_WRITE|FILE_GENERIC_READ
    ShareAccess: FILE_SHARE_READ
    Disposition: FILE_OPEN_IF (3)
    Attributes: 128 (0x80)
    Options: 96 (0x60)
CreateFile status = c0000035
###GetFileInfo 0095
GetFileInfo: : \A\test_file.txt
    result =  0
    FileBasicInformation
    DispatchQueryInformation result =  0
###GetFileInfo 0095
GetFileInfo: : \A\test_file.txt
    result =  0
    FileInternalInformation
    DispatchQueryInformation result =  0
###GetFileInfo 0095
GetFileInfo: : \A\test_file.txt
    result =  0
    FileStandardInformation
    DispatchQueryInformation result =  0
###GetFileInfo 0095
GetFileInfo: : \A\test_file.txt
    result =  0
    FileInternalInformation
    DispatchQueryInformation result =  0
###GetFileInfo 0095
GetFileInfo: : \A\test_file.txt
    result =  0
    FileStandardInformation
    DispatchQueryInformation result =  0
###GetFileInfo 0095
GetFileInfo: : \A\test_file.txt
    result =  0
    FileStandardInformation
    DispatchQueryInformation result =  0
###SetFileInfo 0095  20
SetEndOfFile: \A\test_file.txt, 0
    DispatchSetInformation result =  c0000022
###Create 0096
CreateFile: \A
    DesiredAccess: SYNCHRONIZE|FILE_READ_DATA
    ShareAccess: FILE_SHARE_DELETE|FILE_SHARE_WRITE|FILE_SHARE_READ
    Disposition: FILE_OPEN (1)
    Attributes: 0 (0x0)
    Options: 33 (0x21)
CreateFile status = 0
###GetFileInfo 0096
GetFileInfo: : \A
    result =  0
    FileBasicInformation
    DispatchQueryInformation result =  0
###FindFiles 0096
FindFiles: \A
index from 0
FileMatch? : . (test_file.txt,0,0)
FileMatch? : .. (test_file.txt,0,0)
FileMatch? : test_file.txt (test_file.txt,0,0)
  =>return single entry
index to 1
###Cleanup 0096
Cleanup: \A

###Close 0096
Close: \A

###Cleanup 0095
Cleanup: \A\test_file.txt

###Close 0095
Close: \A\test_file.txt

###Create 0097
CreateFile: \A\test_file.txt
    DesiredAccess: FILE_READ_ATTRIBUTES
    ShareAccess: FILE_SHARE_DELETE|FILE_SHARE_WRITE|FILE_SHARE_READ
    Disposition: FILE_OPEN (1)
    Attributes: 0 (0x0)
    Options: 2097152 (0x200000)
CreateFile status = 0
###GetFileInfo 0097
GetFileInfo: : \A\test_file.txt
    result =  0
    FileNetworkOpenInformation
    DispatchQueryInformation result =  0
###Cleanup 0097
Cleanup: \A\test_file.txt

###Close 0097
Close: \A\test_file.txt

[Lucasq11]

I noticed that dokan made another create operation upon directory A, which is the parent of file I truncated. Is it because parent directory says the file acturely has truncate right? If so, can I prevent this? I want to aquire the right of a file by sending http requests to the server and use the response to judge whether the file has right rather than asking its parent dir, is it able to do so?

[Liryna]

Hi @Lucasq11 , This seems to be one of these cases where it is difficult to perfectly map Window perm and cloud. Yes, the parent permission does count when looking at the child permission.

What kind of error do you expect from the SetEndOfFile failure ? I believe Dokan does correctly forward your error code but it is up to the OS / App to display an error after receiving it.

[Lucasq11]

Hi @Liryna, I'd like the windows to pop up an error box says something like: "no access to truncate the file" after SetEndOfFile returns STATUS_ACCESS_DENIED

[Liryna]

In this case, the application doing the call would have to check the value we returned it and display this error. There is not much we can do here. You can use procmon to confirm the error is correctly returned to user land.