You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 6, 2024. It is now read-only.
In the function SetFsoDateTimeCore(), there is a conditional set of flags/attributes for the underlying CreateFile() native function call.
The initial flags/attributes set for the call is determined by this line in the function: var attributes = isFolder ? ExtendedFileAttributes.BackupSemantics : ExtendedFileAttributes.ReadOnly;
This is problematic for a couple of reasons:
This function calls CreateFileCore() with FileMode.Open (value of '3') which corresponds to CreateFile's dwCreationDisposition of OPEN_EXISTING. According to documentation (see https://msdn.microsoft.com/en-us/library/windows/desktop/aa363874(v=vs.85).aspx) all FILE_ATTRIBUTE_* values passed to CreateFile's dwFlagsAndAttributes parameter are ignored when opening existing files and only FILE_FLAG_* values are honored. For this reason, the use of the ExtendedFileAttributes.ReadOnly is useless for existing files, anyway.
Trying to set any file times for files that can only be accessed via privilege elevation require the BackupSemantics flag to be in play. It is currently not possible to use AlphaFS to set file times for files that are "blocked" for the current user (e.g. no effective allow ACEs in play), even if that user has the ability to override security checks via the Restore privilege.
I'm not sure why the distinction is made between files and folders for this function. My local fix is to simply always set the BackupSemantics flag, and remove the check for isFolder. However, once that is done, this function no longer has any use for the isFolder parameter, and all calling functions should be cleaned up to not pass this parameter anymore.
Let me know if I should create a patch for this function and all calling functions, and whether there is some other functionality or side effect I'm just missing here as for why this was setup this way in the first place.
Thanks!
The text was updated successfully, but these errors were encountered:
In the function
SetFsoDateTimeCore()
, there is a conditional set of flags/attributes for the underlyingCreateFile()
native function call.The initial flags/attributes set for the call is determined by this line in the function:
var attributes = isFolder ? ExtendedFileAttributes.BackupSemantics : ExtendedFileAttributes.ReadOnly;
This is problematic for a couple of reasons:
This function calls
CreateFileCore()
withFileMode.Open
(value of '3') which corresponds to CreateFile's dwCreationDisposition ofOPEN_EXISTING
. According to documentation (see https://msdn.microsoft.com/en-us/library/windows/desktop/aa363874(v=vs.85).aspx) all FILE_ATTRIBUTE_* values passed to CreateFile's dwFlagsAndAttributes parameter are ignored when opening existing files and only FILE_FLAG_* values are honored. For this reason, the use of theExtendedFileAttributes.ReadOnly
is useless for existing files, anyway.Trying to set any file times for files that can only be accessed via privilege elevation require the BackupSemantics flag to be in play. It is currently not possible to use AlphaFS to set file times for files that are "blocked" for the current user (e.g. no effective allow ACEs in play), even if that user has the ability to override security checks via the Restore privilege.
I'm not sure why the distinction is made between files and folders for this function. My local fix is to simply always set the BackupSemantics flag, and remove the check for isFolder. However, once that is done, this function no longer has any use for the isFolder parameter, and all calling functions should be cleaned up to not pass this parameter anymore.
Let me know if I should create a patch for this function and all calling functions, and whether there is some other functionality or side effect I'm just missing here as for why this was setup this way in the first place.
Thanks!
The text was updated successfully, but these errors were encountered: