Implementing the "Easy"-Dokan-API #35
Conversation
Re-added API for conversion from java.nio.file.attribute.FileTime to com.sun.jna.platform.win32.WinBase.FILETIME
Jt develop
Added DokanFileInfoFlag to aid in creating a wrapper ("DokanFileHandle") for DokanFileInfo's getters (e.g. isDirectory())
Added FileShareAccess to wrap paramter rawShareAccess of DokanyFileSystem#zwCreateFile to aid in creating a wrapper ("EasyDokanFileSystem") for DokanyFileSystem
Added MicrosoftReparsePointTag to wrap field dwReserved0 of WinBase.WIN32_FIND_DATA to aid in creating a wrappe ("FindFileInfo") for WinBase.WIN32_FIND_DATA (used by DokanyFileSystem#findFiles)
This commit is part of my effort to fix dokan-java's issue 32 (dokan-dev#32): Adding wrappers for high-level programming
Added EasyFileInfo to wrap the result of DokanyFileSystem#getFileInformation (ByHandleFileInformation)
and Added FindFileInfo to wrap the result of DokanyFileSystem#findFiles (WinBase.WIN32_FIND_DATA) to aid in creating a wrapper ("EasyDokanFileSystem") for DokanyFileSystem
Added AbstractFileInfo as common base class for FileInfos (like EasyFileInfo and FindFileInfo)
Added DefaultFileTimePolicy to help in returning valid FileTimes to Dokan if unavailable to AbstractFileInfo
This commit is part of my effort to fix dokan-java's issue 32 (dokan-dev#32): Adding wrappers for high-level programming
Restored VolumeInformation from commit 99bcbda (party reverting commit 3c343eb) to wrap the result of DokanyFileSystem#getVolumeInformation to aid in creating a wrapper ("EasyDokanFileSystem") for DokanyFileSystem This commit is part of my effort to fix dokan-java's issue 32 (dokan-dev#32): Adding wrappers for high-level programming
Moved VolumeInformation from original package dev.dokan.dokan_java.legacy.structure to dev.dokan.dokan_java.wrappers
Added DesiredAccessMask to wrap parameter desiredAccess of DokanyFileSystem#zwCreateFile to aid in creating a wrapper ("EasyDokanFileSystem") for DokanyFileSystem
Added DiskSpaceInfo to wrap the result of DokanyFileSystem#getDiskFreeSpace to aid in creating a wrapper ("EasyDokanFileSystem") for DokanyFileSystem
This commit is part of my effort to fix dokan-java's issue 32 (dokan-dev#32): Adding wrappers for high-level programming
Added EasyDokanyFileSystem as wrapper for DokanyFileSystem Added DokanyFileHandle to wrap parameter dokanFileInfo (DokanFileInfo) in various methods of DokanyFileSystem Added SecurityContext to wrap parameter securityContext (WinBase.SECURITY_ATTRIBUTES) of DokanyFileSystem#zwCreateFile Added Annotation NativeName to ease the use of NotImplemented on methods of EasyDokayFileSystem that have a name that differs from their counterpart in DokanyFileSystem
Renamed SecurityContext to EasyDokanIOSecurityContext to match the fix in the low-level API (Change from WinBase.SECURITY_ATTRIBUTES to DokanIOSecurityContex as argument of DokanFileSystem#zwCreateFile)
Added MountInfo-API to wrap the class DokanOptions for the respective field in DokanFileHandle (wrapper for DokanFileInfo). Added Interfaces ROMountInfo and RWMountInfo Added ImmutableMountInfo and MountInfo as implementations This commit is part of my effort to fix dokan-java's issue dokan-dev#32
Added ForwardingFileSystem as delegator for method-calls between EasyDokanFileSystem-implementations and DokanFileSystem-API Added EasyDokanFileSystemStub as stub for implementations of EasyDokanFileSystem (similiar to DokanFileSystemStub) Added AbstractEasyDokanFileSystem as base class for implementations of EasyDokanFileSystem (similiar to AbstractDokanFileSystem) This commit is part of my effort to fix dokan-java's issue dokan-dev#32
|
As it was discussed between @JaniruTEC and me: The file system should give a developer the Win32API Flags and should return Win32API error codes, which will be automically converted to an NtStatus code (via |
|
@infeo Does Win32 error are usually used by Java developers? Like they would understand easier the usage compared to ntstatus? |
|
I don't want to speak for every Java developer out there, but from my experience it is. As an example, let's look at the case if an object alrady exists:
As a Java dev you are used to nio exceptions like FileAlreadyExistsException, which directly translates to the win32 error code in this case. The filesystem proposed in this PR should be easier for developers to use and more Javaish, and from my point of view the normal developer deals either only with Java or at most the win32API, but not the Kernel. Of course it would be more desireable to do it more the Java way and catch exceptions and translate those directly to the correct error code, but i thought one step at a time (; this won't replace the old filesystem. A developer has the possiblitly to choose between the more raw filesystem to implement (less Java, more bitmasks and needs to return NTStatus) and the easy one (more Java, gives user land flags and returns win32 codes) |
|
@Liryna What is your opinion? Is it a good plan to use Win32 API codes and flags or should we stick to the Kernel-Layer in the easier-to-use-filesystem? |
|
Thank for your detail! case like |
JaniruTEC
changed the title
Fixed wrong implements-statements Added missing convenience methods Renamed parameters/fields Replaced outdated constructors Replaced outdated methods
Added ReparsePointTag as base interface for all ReparsePointTags (extends EnumInteger) Changed MicrosoftReparsePointTag to implement ReparsePointTag Changed signature of generic/non-MS-specific methods in FindFileInfo to use ReparsePointTag-Interface See: https://docs.microsoft.com/en-us/windows/win32/fileio/reparse-point-tags https://web.archive.org/web/20200603151710/https://docs.microsoft.com/en-us/windows/win32/fileio/reparse-point-tags
Updated DokanFileHandle to use ROMountInfo instead of DokanOptions Added setFileInfo method This commit led to discovery of dokan-dev#46 which leads to problems with this code.
Added check if only a single bit (flag) is set to make sure that getFlag returns reliable results
Added check if only a single bit (flag) is set to make sure that updateFlag operates reliably Externalized check
Created BasicDesiredAccessMask as base class for DesiredAccessMask Moved all methods concerning basic rights to the new base class Renamed getFileAccessMask to getFileAccessMaskFlag to reflect the changes to the AccessMaskFlags
Fixed Conflicts: src/main/java/dev/dokan/dokan_java/structure/DokanOptions.java
No description provided.