Dokan.NET 0.1.7 released
Dokan.NET 0.1.7 is released.
Dokan.NET is a .NET wrapper for Dokan library. You can write a file system in C# using Dokan.NET.
Changes from 0.1.6
- Added VolumeLabel parameter to DokanOptions
- Added GetDiskFreeSpace to DokanOperations
public class DokanOptions
{
public char DriveLetter;
public uint ThreadCount;
public bool DebugMode;
public bool UseStdErr;
public bool UseAltStream;
public string VolumeLabel;
}
GetDiskFreeSpace is like GetDiskFreeSpaceEx.
http://msdn2.microsoft.com/en-us/library/aa364937(VS.85).aspx
int GetDiskFreeSpace(
ref ulong freeBytesAvailable,
ref ulong totalBytes,
ref ulong totalFreeBytes,
DokanFileInfo info);
You can see some samples under DokanNet\sample.
Thanks for the update, will check it out soon as I get back from my trek.
HarryH.
Question, before I update to vista… does this work on vista ?
Hi, HarryH
Dokan library works on both 32bit version of Vista and XP.
Hiroki, I’m looking to build a component that I would love to use your Dokan Library with, can you tell / email me how I can package my app and your components and not break copywrite.
I’m not looking to charge for my app that I’m building, but would like to have one install oppose to an install and a link to your site, but hoping we can work something out.
Thanks
Harry H.
Hi, HarryH
Dokan.NET is MIT license, so you can use freely use it.
You can modify and redistribute Dokan.NET with the original
MIT license file included in Dokan.NET.
I have a plan to change the license of Dokan library,
but it needs a week or more.
In this time, please not contain Dokan library in your software
and link to my download page.
Thanks
thanks Hiroki, I didn’t see the license agreement before.
I will not post your link to the download.
Another question - any plans to have support for 64bit ?
Yes, I’ll release 64 bit version.
But, in order to make a 64 bit driver, I need a electronic signature
and only a company can get it, so I have to overcome some obstacles.
I’m not sure when I can release 64 bit version now.
Hi,
thanks for the update.
don’t know how much it’s gonna cost to get the signature, but willing to do a donation towards it.
just let me know when you ready.
Hiroki, I’m having an issue. I have a directory that contain 528 files, when I attempt to display that directory inside my Virtual FS, it shows only 117 objects (however the count within findfiles functions for arraylist has the proper count, I replicated the same issue utilizing DokanNetMirror and the same exact behavior has shown up, only 117 files gets displayed.
if I may bother you plz, can you tell me what is the cause of this and how I may go about resolving it, I would greatly appreciate it.
Many Thanks again
Harry H.
btw - one more note I forgot to mention, the files are being displayed on a remote client windows explorer, not the same PC (I have the drive as network shared), on the same PC I see 171 files not the 117 as the remote client sees, and not the 528 I expected to be seeing.
Hi, I couldn’t reproduce your bug. I made 600 files in a folder and accessed through DokanNetMirror, and I could get 600 files there.
Can you show me the minimum size code that occur the bug?
Hi, I’m certain there’s something weird there, but great to hear that you’re not having the issue.
I will play with it some more and if I get to replicate the issue
I will send you how to make it happen.
Thanks.
Ok,
I’m still able to replicate the issue..
1 - Create a folder (C:\Changers\Devices\A0000001) with 511 objects (Some filenames must have a length of over 110 characters).
2- make dokanmirror the root of “c:\changers\Devices” on host pc.
these objects will show with proper count and file listing thru dokanmirror on the host pc (randomly not, but it’s hard to get it to do so), however when you run dokanmirror app and take the virtual driver and make exposed as shareable, when you attempt view this folder on a client pc (different pc completely) Using explorer you will see that you only get limited set of files attempting to view the virtual drive via the exposed share.
I have attempted this several times and this still keeps showing the same behavior on the client pc, however it’s random on the main PC (the server pc with the virtual drive), but very duplicable on the client pc accessing the files.
I have three files in that directory that extend over the 110 character for a filename.
Please let me know if you would like further information regarding this.
Hi, HarryH
I could reproduce your problem. I made 500 files which name have more than 200 charactors. When I mount a drive using Dokan mirror, I got same problem with you.
I think this is a driver’s problem. I want to fix it in this weekend.
Thanks
Many thanks for taking a look at it for me.. I appreciate it.
Let me know if there’s something else I can do or test.
Thanks Again,
Harry H.
Hello,
I discovered this wonderful project last week and I’m now trying to use it.
I just wanted to know if there will be a complete set of errors. What I’m meaning is something like an enum with errors like NO_SUCH_FILE, ACCESS_DENIED, etc., which will the return value for each functions.
I apologize for my english, i’m french.
Stan.
Hello,
I defined three error constants in DokanNet.
public const int ERROR_FILE_NOT_FOUND = 2;
public const int ERROR_PATH_NOT_FOUND = 3;
public const int ERROR_ALREADY_EXISTS = 183;
Actuary Dokan can handle bellow error codes.
I think DokanNet should have these codes,
so I’ll put those on next DokanNet release.
ERROR_FILE_NOT_FOUND
ERROR_PATH_NOT_FOUND
ERROR_ACCESS_DENIED
ERROR_SHARING_VIOLATION
ERROR_INVALID_NAME
ERROR_FILE_EXISTS
ERROR_ALREADY_EXISTS
You can find error code definitions on MSDN System Error Codes.
http://msdn.microsoft.com/en-us/library/ms681382(VS.85).aspx
Thanks
Thanks for your help.
I hope an enum will be there in the next release too !
Your project is quite perfect, continue like that !
I’d like to know if in a next release of Dokan Lib or Dokan.NEtT a function to get IOAccess will be available. This may be very usefull for file recovery soft users, to make file recovery possible on a particular FS. Thanks
Hello, dvkch
Did you mean DeviceIOControl?
If so, could you tell me more details or give me the pointer of documents about usage of it?
Hi Hiroki,
by any chance did you get to look at the issue i had describe a couple back ?
any chance of getting a fix on it ?
thanks
Harry H.
Hello, Harry
I’m doing for two weeks, but not yet fixed it. It’s a very difficult bug.
Hello Hiroki,
Yes, i was talking about the DevicIOControl which is described in this paper : http://msdn.microsoft.com/en-us/library/aa363216(VS.85).aspx . I think it’s not really difficult to implement (since it’s a windows base function), and I hope it’ll be easy for you ! If I could do any test to help you, just ask me !
Many thanks again,
DvkCH
Hello,
I just read your last post about the next opensource release of DokanLib, and wanted to know if you took a look at the DeviceIOControl API to see if it will be implemented or not.
Thanks.
Hello, dvkch
I saw DeviceIOControl API document. Dokan library uses some device control codes to control the Dokan driver. I think other unused codes can be passed to user-mode and hooked. I think about supporting device io control in feature version.
Thanks
Hi Hiroki,
I’m having a little problem with the interaction of the two functions “GetFileInformation” and “ReadFile”. The premise is that I am dealing with files whose final filesize I don’t know until I actually read them. This is due to the fact that I need to add some metadata to each file before I can return it (in the ReadFile function). This adding of metadata makes the file slightly larger.
Although doing the file-modfication in the “GetFileInformation” function and then setting “fileinfo.Length” to the correct filesize would solve this problem, this is not an option for me because it would make the browsing very sluggish. AFAIK, “GetFileInformation” even gets called when the user moves the pointer over a certain folder.
So for now in “GetFileInformation” I set “fileinfo.Length” to “file-size before metadata was added” + “2048kb padding for metadata”. Then in “ReadFile” I do my file modification and return the new file. The problem is that in most cases the metadata added to the file is nowhere around 2048kb but rather around 10kb. So the file I return in “ReadFile” is smaller than it was announced in the “GetFileInformation” function, which I signal back to Windows by setting “readBytes” to the new filesize.
But somehow, Windows doesn’t manage to free the “unused” 2038kb. A rather drastic, but possibly simpler example illustrates this:
If you always set
- “fileinfo.Length” to 10.000.000 (10MB) in “GetFileInformation” for every file
- just write 1MB to the buffer you get handed in “ReadFile”
- set “readBytes” to 1MB in “ReadFile”
Then I would expect explorer.exe to free the remaining 9MB. Instead, it just bloats. The memory isn’t even freed after I quit my program. Only killing explorer.exe and restarting it solves the problem.
Is there a way to fix this issue, or is the behavior normal?
Regards
Hello, Sebastian
Sorry I didn’t try by myself, but why explorer gets 10MB memory? To generate thumbnail of image? How did you examine that explorer didn’t free 9MB of memory?
“readBytes” means actually how many bytes ReadFile function read file at each call. You must set returned bytes on readBytes (how many bytes you wrote to the argument buffer, not file size).
Could you check it?
Hi Hiroki!
Yes, in my case, I have a photo and need to add some metadata and a thumbnail pic to the photo’s header in the ReadFile function. That’s why, in the GetFileInformation function, I set fileinfo.Length to “photo.size + 4096″ to give some room for the information.
I observed the explorer’s memory usage via the ProcessExplorer.
About “readBytes”…..I think I am using it as intended. I set it to the amount of data I have written to the argument buffer. But if I set “fileinfo.Length” to 10MB (in GetFileInformation), the argument buffer will have the size 10MB. If I then only write 1MB to it (because I didn’t add a lot of metadata), I set readBytes to 1MB. But it seems that the explorer doesn’t free the remaining 9MB of the argument buffer.
Is there anything that you can do from your side or is this an explorer issue?
Hello, Sebastian
I verified your problem. Whenever GetFileInformation is called, I add some extra bytes to file.length. In this case, Explorer seems not to free that memory. I don’t have no idea where memory is not freed.
Can you cache GetFileInformation for each file to prevent recalculation of file length?
BTW, I wonder what happened when you set file length to the size before adding metadata.