Liquesce testing..!!

The initial touch testing of Liquesce in Win 7 x64 was very encouraging, and I was able to mark some outstanding issues as closed;

BUT

Dropping back to using XP as the Mount server is proving, that things like Notepad are not happy with the new code base.

Also Creating files or directories in XP explorer does not bring up the rename box. So something is not right.

So, A question I need to answer is, Do I support XP as the server ? or just move onto Win7 and above (x32 and x64)!

I will have to see how much code needs to be sorted, and how many other problems are found in the more extensive testing in x64 OS’s..

The summary is – Steps forward in Win7 but steps backward in XP.. It’s a little frustrating. Anyone else performing any testing ?

Advertisements

Liquesce and file security…

It’s been a frustrating few evenings (well 5 actually !) trying to sort out what was being done in Windows 7 x64 with the GetFileSecurity API and then what Explorer was showing me.

It turns out there are issues with how Dokan and Explorer treat each other, and then it’s all different when the same files are being accessed over a share to those same locations:

 

1) ACL’s not on NTFS drives

This caught me out, because the source format type, can be anything that windows recognises, then the API’s still have to work as if they have ACL (Because that is what Liquesce states as being supported). Now, this means that if the source type is anything other than a type that does not have ACL, then explorer (And other apps) do not know this.

Lets show you in some pictures, these are generated via the Liquesce Mount, but their underlying sources are different:

FAT32 (Kylie) NTFS (Test1)
FAT32 NTFS

So the files(directories) without ACL, are shown with a padlock padlock, and when going into the security tab of properties, you can see that “No permissions have been assigned etc."; and if you attempt to apply then it fails (Silly message box for every directory inside the parent).

The NTFS Test1 works as expected.

 

2) ACL access via a share

Explorer requests an additional ACL level when accessing files via a share = SACL_SECURITY_INFORMATION

This needs special permissions to retrieve and also access to certain levels of the OS API’s. Even running as a service and setting a manifest file with the permissions set to “highestAvailable”, the code that actually calls the GetFileSecurity API does not get the expected result. Sad smile

Returning access denied to explorer just stops it going any further, so that is not helpful. The (current) answer is to go and implement the workaround mentioned in http://code.google.com/p/dokan/issues/detail?id=209

So what’s next? Well Testing on all the supported platforms, and some additional text in the testing procedure Smile

A Liquesce update.

I have been battling the x64 FileSecurity API’s that display who has what access in explorer. It seems that the API call works, but then displays an empty field in Explorer, then When setting the data, it comes back with incorrect information, and the CreateFile (Open method in Dokan) does not pass the security credentials through that Explorer is trying to use to determine if it has those ACL rights..

Seems like Dokan is shooting itself in the foot again.

The easy way out (At the moment) is to just disable ACL on the Mounted drive And disable those API’s as well. But then that stops things like word etc from opening and closing files properly (I think that is what it comes down to ?)

So Back to the discovery as to why Dokan is still coming up short for even a small fix in that direction of compatibility win Win 7 higher!