This project has moved. For the latest updates, please go here.

More than one spanning drive

Sep 11, 2010 at 7:04 PM

Hi!

First of all I have to say THANK YOU for the good work. It seems that Liquesce is reaching a state where it is usable.

 

But do you say about this plan:

Let's say I have multiple drives:

1 SSD, some HDD.

I wan't to make 3 virtual drive spans

1. Data (SSD + all data HDD)

2. Data_cleanup (all data HDD without SSD)

3. Backup (all backup HDD)

 

With this configuration I could copy on my Data drive with maximum speed (if the SSD is the first drive to use for Liquesce).

In the night I could configure an automated move from SSD to Data_cleanup to empty the SSD.

Once a week I'd sync some folders (which are larger than 2TB) to the Backup.

 

This would be the perfect configuration for me. Only things that are missing are:

Liquesce has to support multiple virtual drives.

Configuration of pysical drive's write priority.

 

I'd love to see these features and I hope some of you would agree ;)

Coordinator
Sep 11, 2010 at 7:51 PM

Comments below (in blue)

First of all I have to say THANK YOU for the good work. It seems that Liquesce is reaching a state where it is usable.

Thanks, I'm playing with the Tray GUI at the moment..

With this configuration I could copy on my Data drive with maximum speed (if the SSD is the first drive to use for Liquesce).

Liquesce will copy to the first drive that holds that directory until the drive buffer hold off (Advanced settings in the Config file at the moement) is reached.

In the night I could configure an automated move from SSD to Data_cleanup to empty the SSD.

OK.. Why, as the copy over ethernet would be the slowest. I have just got Sata ]['s and get > 100MB/s over Gigabit. It's the drive controller that does the magic.. It's running off a PCIExpress x8 card..

Once a week I'd sync some folders (which are larger than 2TB) to the Backup.

OK

This would be the perfect configuration for me. Only things that are missing are:

Liquesce has to support multiple virtual drives.

It should be possible, just have to replicate the data in the Config file, and then fire off the threads to keep the work items seperate.

Configuration of pysical drive's write priority.

Already done, in that it uses wherever it finds the directory your writing to first.
And new Dir's currently always go to the 1st drive in the list.
 

I'd love to see these features and I hope some of you would agree ;)

Should all be possible once the MultiConfig file feature has been added.

I'll add this into the Plan for a Phase 2 feature.

Sep 11, 2010 at 9:12 PM

Nice... I can't wait until multiple pools are possible. :-D

 

To the SSD thing...

I have to think about this one more time... The real benefit would be an activity analysis from the whole data. These files should be placed then on the SSD.

Like an cache implementation for Liquesce... (woa... would this be cool...)

 

But right now I think there are other things to do, so I tried to make the best of it and add the SSD as high priority device to the pool. But you are right, since there is no activity analysis of the files, the won't be a real benefit.

Coordinator
Sep 12, 2010 at 9:27 AM

A priority style thing has been propsed by NLS in another discussion, but he went further and hinted at something like having "Green policy"

Also in that long stream of comments was something for having a priroty where the drives area used in loading manner, then (At some predetermined time) it would then re-adjust the drive layouts

e.g. (If I understand / remember correctly)

- Movies drive has space and contains a pictures dir.

- More movies are added and the space is used up and the some movies are moved onto another drive

- The scheduled task would then see that a directry was spanning a disk and then attempt to move the pictures onto the drive with space, and then move the movies back together.

It all sonds great but would be a bit of a testing nightmare when is comes to the edge conditions (Like not enough space anywhere!)

Feb 25, 2011 at 6:39 AM
smurfiv wrote:
Liquesce will copy to the first drive that holds that directory until the drive buffer hold off (Advanced settings in the Config file at the moement) is reached.


Firstly, thanks for making this software, it's exactly what I was after, and it's working better than "flexraid view" that I started with... but is this file placement algorithm still working correctly in the latest release available today which I just downloaded?

When I copy a file to an existing directory on a drive somewhere in the middle of my configuration, which has 80GB free, it still creates a new directory on the 1st drive (which also has plenty of space available) and puts the file there!

In my setup, I try to manage space manually as much as possible but with my admittedly limited testing, this behaviour is going to cause problems for my automated backup software.  I don't mind it going from drive 5 (say) which has the first seen sub-directory, then to 6 which also has the sub-directory, then to 1 if no more space exists... but to use drive 1 as the default because it has ample space available isn't quite what I'm looking for.

Coordinator
Feb 25, 2011 at 7:24 AM

There are now 3 "Placement" algorithms- Yours sounds like it is in the default "Priority" mode. have a look at the following link for a description of each.

"http://liquesce.codeplex.com/wikipage?title=How%20are%20the%20files%20spread%20across%20the%20drives%20%3f"

As part of the Phase II re-write, I am aiming to make the usage and visibility of these modes a little clearer.

Feb 25, 2011 at 9:19 AM
Edited Feb 25, 2011 at 11:40 AM

Ahh, yes - I see I was in the "Priority" mode and it's working the way I want now with the setting change (after a reboot, ..simply "sending" the change didn't work).  That's brilliant, thanks for the (fast reply and) link to the required information.

Incidentally, I normally hibernate the machine with all my media disks in it, but I've noticed that I sometimes (well, twice today so far) get a BSOD when powering up the machine again.  As this is a beta, that's OK, but is it something that's been reported already and is it being looked at (by you or the DOKAN guy/team?)  I've tried to repeat the issue, but the last time I woke the machine it all worked perfectly, so it seems a little bit intermittent.  I wouldn't say it happens more often than not because I powered up the machine multiple times today without issues.. but it did happen twice in a row about an hour ago.

The first time it occured Windows wanted to "chkdsk" my O: drive on the full-restart, that drive is completely blank too!  (Not usually something I see when a machine reboots unexpectedly!)

Having visited the DOKAN site today (how I found this site) I expect any BSOD's to be something wrong in that area since it's doing all the kernel work, correct?

(EDIT: I say "blank", and I mean "was blank before" - so nothing was lost or anything, just that it's strange that Windows thinks a blank disk is due for a scan because of an unscheduled reboot.. no cause for alarm!)

Coordinator
Feb 25, 2011 at 11:40 AM
Jaso wrote:
Incidentally, I normally hibernate the machine with all my media disks in it, but I've noticed that I sometimes (well, twice today so far) get a BSOD when powering up the machine again.  As this is a beta, that's OK, but is it something that's been reported already and is it being looked at (by you or the DOKAN guy/team?)  I've tried to repeat the issue, but the last time I woke the machine it all worked perfectly, so it seems a little bit intermittent.  I wouldn't say it happens more often than not because I powered up the machine multiple times today without issues.. but it did happen twice in a row about an hour ago.

As you mentioned "FlexRaid View", I have a feeling you are suffering from it's BSOD's that are documented on their site...

I have not read of any reports of the DOKAN BSOD since V0.4.

Feb 26, 2011 at 12:25 AM
Edited Feb 26, 2011 at 2:59 AM

I uninstalled (closely following the documented steps) FlexRaid (and View) and rebooted the machine before starting with Liquesce.  There were no "leftovers" either, I deleted the remaining files (logs) and just checked that the DOKAN files now there were from the V0.6 (2011/01/10) release, which they are.

I just downloaded the symbols for Win7x86 so I could see what was in the 2 minidumps, they are both the same and look like this: (stack trace)

nt!ExFreePoolWithTag+0x1b1 <- crash occurs here
nt!IopDereferenceVpbAndFree+0x3a
nt!IopParseDevice+0x1121
nt!ObpLookupObjectName+0x4fa
nt!ObOpenObjectByName+0x159
nt!IopCreateFile+0x673
nt!NtOpenFile+0x2a
nt!KiFastCallEntry+0x12a
0x76e264f4

Each minidump had a different base for the last entry (and are in user-land) 0x76e2 & 0x770e - but both ends with 64f4 - At first I suspected it could be ntdll.dll KiFastSystemCallRet (77f064f4) and looking at the "running" Liquesce service in Process Explorer, ntdll.dll is being relocated from 77f0 to somewhere else each reboot.  But as this is a return address in the stack, that doesn't really make sense.  I have not seen the BSOD happen again though, and I've tried many times since.

Edit: This is the Analyze output: (says the process was explorer.exe too..)

Arg1: 00000007, Attempt to free pool which was already freed
Arg2: 00001097, (reserved)
Arg3: 080c0002, Memory contents of the pool block
Arg4: 88167ef0, Address of the block of pool being deallocated

One annoying thing which is happening when I resume from Hibernate (or Sleep) is that the DOKAN drive letter disappears until I "send" the configuration again in your application.  Is this meant to happen?  I have got the machine configured to wake/hibernate with the power switch, so I wouldn't normally switch on the monitor for that machine - but I have to at the moment to get the virtual drive back.  I'm sure there was one or two occasions the drive was still there and working upon waking - and maybe the two BSOD's were from it "half" being there in some inconsistent state?

Coordinator
Feb 26, 2011 at 8:24 AM

Thanks for the clarification on the FlexRaid stuff.
You obviously have a time stamp of the minidumps, so can you have a look for the Service Log files and attach to the "Issue" that I will create in a moment (At the bottom of this reply).

Where are the logs:
"http://liquesce.codeplex.com/wikipage?title=How%20To%20Get%20Logs&referringTitle=FAQs"

Also do you have the timestamps of when you attempted to make the machine go into hibernate, and then the wakeup times as well ?

Can you also state what version of Liquesce you are using as well, and add them to the issue details? (Any other details from this thread will need to be added like OS version and SP ?)

"http://liquesce.codeplex.com/workitem/8418"

Feb 26, 2011 at 12:17 PM

I will check/do these things tomorrow morning, it's getting late here (past 10pm) but I thought I'd just log onto the Internet to have a quick look at where things are at before I go to sleep.

Also, I logged on just to mention, I tried Liquesce (ver. 2011.2.15.622 - from the file properties of the service exe) on another Windows 7 Home x86 machine (with zero updates from the Internet - as it's not connected, no SP either yet) and it also has the problem with the drive disappearing when "waking" - but not all the time - I had to hibernate it 3 times before it happened on this machine.  Both machines are very different, but have quite fresh installs of Windows 7 on them.  The 2nd machine I tried doesn't have anything extra installed except winzip and vlc, where the first has quite a few extra things installed now.

Finally, I need to mention that my software which duplicates files (as a backup) attempts to set the file-modified-date after finishing copying all the bytes, however with my 1 attempt (it's getting late, remember!) at doing a copy with this software, it didn't set the date from "now" (as the copy starts as a normal create file operation) to what it needs to be (date and attributes) for the software to check that the file is now unchanged/unaltered.  I know this software uses the MSVC "SetFileTime" and "SetFileAttributes" API function calls on the network share file (in this case) and it does work normally (I've never had a failure in many files copied before using this product).  Is this particular functionality not provided [yet?] by Liquesce?

Coordinator
Feb 26, 2011 at 12:35 PM
Jaso wrote:
1)  tried Liquesce (ver. 2011.2.15.622 - from the file properties of the service exe) on another Windows 7 Home x86 machine (with zero updates from the Internet - as it's not connected, no SP either yet) and it also has the problem with the drive disappearing when "waking" - but not all the time - I had to hibernate it 3 times before it happened on this machine.  Both machines are very different, but have quite fresh installs of Windows 7 on them.  The 2nd machine I tried doesn't have anything extra installed except winzip and vlc, where the first has quite a few extra things installed now.
2) Finally, I need to mention that my software which duplicates files (as a backup) attempts to set the file-modified-date after finishing copying all the bytes, however with my 1 attempt (it's getting late, remember!) at doing a copy with this software, it didn't set the date from "now" (as the copy starts as a normal create file operation) to what it needs to be (date and attributes) for the software to check that the file is now unchanged/unaltered.  I know this software uses the MSVC "SetFileTime" and "SetFileAttributes" API function calls on the network share file (in this case) and it does work normally (I've never had a failure in many files copied before using this product).  Is this particular functionality not provided [yet?] by Liquesce?

1) Added the details to the Issue 8418, If you can add the logs from the test machine that would be great.

2) Can you state what is the Backup S/W and version. As I have used Teracopy, and they have changed how they perform some of their write locks in the latest version, which prevent Dokan 0.5.3 mounts from working as expected. I haven't re-tested anything for 0.6.0, that's one of the reason's I have both installers still available.

Feb 26, 2011 at 12:52 PM

You caught me just before I logged off...

This backup software has no name or version - it was written for me specially about 6 years ago - and that's how I know it uses those 2 API calls on the file [/share] which is created remotely.

From looking at the source, it uses "the standard" CreateFile (.., GENERIC_READ | GENERIC_WRITE, .., CREATE_ALWAYS, ..) etc.  Then once all the bytes which can be read/written (using ReadFile (..) and WriteFile (..)) it calls the "SetFileTime" using the same handle, closes the handle and then calls "SetFileAttributes" which uses the char * filename (instead of a handle) which was used in the CreateFile call.  It's all pretty standard stuff, but I'm not really allowed to post the code on the Internet.  Shh!

Feb 26, 2011 at 9:45 PM

Powering up the primary machine today, I got another BSOD with the exact same error, I may have to disable Liquesce for a few days to double check it is DOKAN doing it.  This PC doesn't suffer from BSODs normally, but this will put my mind at rest, I will report back in a week or so.

Looking at the system event log sheds no light on the BSOD either, normally I get: (at time of Hibernate)

Kernel-Power: The system is entering sleep.  Sleep Reason: Application API

Followed by: (at wake time)

Kernel-General: The system time has changed to ... from ...
Power-Troubleshooter: The system has resumed from sleep.  Sleep Time: ... Wake Time: ... Wake Source: Unknown

but when the BSOD occurs, no entries relating to the sleep/wake cycle are there, only this:

Kernel-General: The operating system started at system time ...
EventLog: The previous system shutdown at ... on ... was unexpected.
BugCheck: The computer has rebooted from a bugcheck.  The bugcheck was: 0x000000c2 (0x00000007, 0x00001097, 0x080c0008, 0x9e3f98b8). A dump was saved in: ...

The Liquesce logs don't show much either: (Liquesce.log) (BTW: That time of 6AM isn't right!)

2011-02-25 16:17:42.3336[1][] ERROR Program: =====================================================================
2011-02-25 16:17:42.3492[1][] ERROR Program: File Re-opened: 25/02/2011 6:17:42 AM
2011-02-25 16:17:42.5052[1][] DEBUG Liquesce.MainForm: Create the root node.
2011-02-25 16:17:42.5052[1][] DEBUG Liquesce.MainForm: Now we need to add any children to the root node.
2011-02-25 16:17:42.5052[1][] DEBUG Liquesce.MainForm: Start with drives if you have to search the entire computer.
2011-02-25 16:17:42.5052[1][] DEBUG Liquesce.MainForm: C:\
2011-02-25 16:17:42.5208[1][] DEBUG Liquesce.MainForm: D:\
2011-02-25 16:17:42.5208[1][] DEBUG Liquesce.MainForm: E:\
2011-02-25 16:17:42.5208[1][] DEBUG Liquesce.MainForm: F:\
2011-02-25 16:17:42.5208[1][] DEBUG Liquesce.MainForm: G:\
2011-02-25 16:17:42.5208[1][] DEBUG Liquesce.MainForm: H:\
2011-02-25 16:17:42.5208[1][] DEBUG Liquesce.MainForm: I:\
2011-02-25 16:17:42.5208[1][] DEBUG Liquesce.MainForm: J:\
2011-02-25 16:17:42.5208[1][] DEBUG Liquesce.MainForm: K:\
2011-02-25 16:17:42.5208[1][] DEBUG Liquesce.MainForm: L:\
2011-02-25 16:17:42.5208[1][] DEBUG Liquesce.MainForm: M:\
2011-02-25 16:17:42.5208[1][] DEBUG Liquesce.MainForm: N:\
2011-02-25 16:17:42.5208[1][] DEBUG Liquesce.MainForm: O:\
2011-02-25 16:17:42.5208[1][] DEBUG Liquesce.MainForm: Y:\
2011-02-25 16:17:42.5520[1][] DEBUG Liquesce.MainForm: Z:\
2011-02-25 16:17:42.5676[1][] DEBUG Liquesce.MainForm: Remove the placeholder node.
2011-02-25 16:17:44.2836[5][] DEBUG Liquesce.MainForm: Should now have a huge list of filePaths
2011-02-25 16:17:48.1680[1][] ERROR Program: File Closing
2011-02-25 16:17:48.1680[1][] ERROR Program: =====================================================================
2011-02-25 16:18:07.9016[1][] ERROR Program: =====================================================================
2011-02-25 16:18:07.9172[1][] ERROR Program: File Re-opened: 25/02/2011 6:18:07 AM
2011-02-25 16:18:08.0732[1][] DEBUG Liquesce.MainForm: Create the root node.
2011-02-25 16:18:08.0732[1][] DEBUG Liquesce.MainForm: Now we need to add any children to the root node.
2011-02-25 16:18:08.0732[1][] DEBUG Liquesce.MainForm: Start with drives if you have to search the entire computer.
2011-02-25 16:18:08.0732[1][] DEBUG Liquesce.MainForm: C:\
2011-02-25 16:18:08.0732[1][] DEBUG Liquesce.MainForm: D:\
2011-02-25 16:18:08.0732[1][] DEBUG Liquesce.MainForm: E:\
2011-02-25 16:18:08.0732[1][] DEBUG Liquesce.MainForm: F:\
2011-02-25 16:18:08.0732[1][] DEBUG Liquesce.MainForm: G:\
2011-02-25 16:18:08.0732[1][] DEBUG Liquesce.MainForm: H:\
2011-02-25 16:18:08.0888[1][] DEBUG Liquesce.MainForm: I:\
2011-02-25 16:18:08.0888[1][] DEBUG Liquesce.MainForm: J:\
2011-02-25 16:18:08.0888[1][] DEBUG Liquesce.MainForm: K:\
2011-02-25 16:18:08.0888[1][] DEBUG Liquesce.MainForm: L:\
2011-02-25 16:18:08.0888[1][] DEBUG Liquesce.MainForm: M:\
2011-02-25 16:18:08.0888[1][] DEBUG Liquesce.MainForm: N:\
2011-02-25 16:18:08.0888[1][] DEBUG Liquesce.MainForm: O:\
2011-02-25 16:18:08.0888[1][] DEBUG Liquesce.MainForm: Y:\
2011-02-25 16:18:08.1044[1][] DEBUG Liquesce.MainForm: Z:\
2011-02-25 16:18:08.1044[1][] DEBUG Liquesce.MainForm: Remove the placeholder node.
2011-02-25 16:18:09.7892[5][] DEBUG Liquesce.MainForm: Should now have a huge list of filePaths
2011-02-25 16:18:13.0340[1][] INFO Liquesce.MainForm: Didn't go bang so stop
2011-02-25 16:18:13.0340[1][] INFO Liquesce.MainForm: Send the new details
2011-02-25 16:18:13.0496[1][] INFO Liquesce.MainForm: Now start, may need a small sleep to allow things to settle
2011-02-25 16:18:17.4176[1][] ERROR Program: File Closing
2011-02-25 16:18:17.4176[1][] ERROR Program: =====================================================================

Hibernate->Wake here, with BSOD

2011-02-25 18:13:54.8377[1][] ERROR Program: =====================================================================
2011-02-25 18:13:54.8533[1][] ERROR Program: File Re-opened: 25/02/2011 8:13:54 AM
2011-02-25 18:13:55.0093[1][] DEBUG Liquesce.MainForm: Create the root node.
2011-02-25 18:13:55.0249[1][] DEBUG Liquesce.MainForm: Now we need to add any children to the root node.
2011-02-25 18:13:55.0249[1][] DEBUG Liquesce.MainForm: Start with drives if you have to search the entire computer.
2011-02-25 18:13:55.0249[1][] DEBUG Liquesce.MainForm: C:\
2011-02-25 18:13:55.0249[1][] DEBUG Liquesce.MainForm: D:\
2011-02-25 18:13:55.0249[1][] DEBUG Liquesce.MainForm: E:\
2011-02-25 18:13:55.0249[1][] DEBUG Liquesce.MainForm: F:\
2011-02-25 18:13:55.0249[1][] DEBUG Liquesce.MainForm: G:\
2011-02-25 18:13:55.0249[1][] DEBUG Liquesce.MainForm: H:\
2011-02-25 18:13:55.0249[1][] DEBUG Liquesce.MainForm: I:\
2011-02-25 18:13:55.0249[1][] DEBUG Liquesce.MainForm: J:\
2011-02-25 18:13:55.0249[1][] DEBUG Liquesce.MainForm: K:\
2011-02-25 18:13:55.0249[1][] DEBUG Liquesce.MainForm: L:\
2011-02-25 18:13:55.0405[1][] DEBUG Liquesce.MainForm: M:\
2011-02-25 18:13:55.0405[1][] DEBUG Liquesce.MainForm: N:\
2011-02-25 18:13:55.0405[1][] DEBUG Liquesce.MainForm: O:\
2011-02-25 18:13:55.0405[1][] DEBUG Liquesce.MainForm: X:\
2011-02-25 18:13:55.0405[1][] INFO Liquesce.MainForm: Removing the existing DOKAN drive as this would cause confusion ! [X:\]
2011-02-25 18:13:55.0405[1][] DEBUG Liquesce.MainForm: Z:\
2011-02-25 18:13:55.0405[1][] DEBUG Liquesce.MainForm: Remove the placeholder node.
2011-02-25 18:13:56.7565[5][] DEBUG Liquesce.MainForm: Should now have a huge list of filePaths
2011-02-25 18:15:18.9842[1][] ERROR Program: File Closing
2011-02-25 18:15:18.9842[1][] ERROR Program: =====================================================================

Hibernate->Wake here, with BSOD

2011-02-25 18:44:23.2856[1][] ERROR Program: =====================================================================
2011-02-25 18:44:23.4572[1][] ERROR Program: File Re-opened: 25/02/2011 8:44:23 AM
2011-02-25 18:44:23.6756[1][] DEBUG Liquesce.MainForm: Create the root node.
2011-02-25 18:44:23.6756[1][] DEBUG Liquesce.MainForm: Now we need to add any children to the root node.
2011-02-25 18:44:23.6756[1][] DEBUG Liquesce.MainForm: Start with drives if you have to search the entire computer.
2011-02-25 18:44:23.6756[1][] DEBUG Liquesce.MainForm: C:\
2011-02-25 18:44:23.6756[1][] DEBUG Liquesce.MainForm: D:\
2011-02-25 18:44:23.6912[1][] DEBUG Liquesce.MainForm: E:\
2011-02-25 18:44:23.6912[1][] DEBUG Liquesce.MainForm: F:\
2011-02-25 18:44:23.6912[1][] DEBUG Liquesce.MainForm: G:\
2011-02-25 18:44:23.6912[1][] DEBUG Liquesce.MainForm: H:\
2011-02-25 18:44:23.6912[1][] DEBUG Liquesce.MainForm: I:\
2011-02-25 18:44:23.6912[1][] DEBUG Liquesce.MainForm: J:\
2011-02-25 18:44:23.6912[1][] DEBUG Liquesce.MainForm: K:\
2011-02-25 18:44:23.6912[1][] DEBUG Liquesce.MainForm: L:\
2011-02-25 18:44:23.6912[1][] DEBUG Liquesce.MainForm: M:\
2011-02-25 18:44:23.6912[1][] DEBUG Liquesce.MainForm: N:\
2011-02-25 18:44:23.6912[1][] DEBUG Liquesce.MainForm: O:\
2011-02-25 18:44:23.6912[1][] DEBUG Liquesce.MainForm: X:\
2011-02-25 18:44:23.7068[1][] INFO Liquesce.MainForm: Removing the existing DOKAN drive as this would cause confusion ! [X:\]
2011-02-25 18:44:23.7068[1][] DEBUG Liquesce.MainForm: Z:\
2011-02-25 18:44:23.7068[1][] DEBUG Liquesce.MainForm: Remove the placeholder node.
2011-02-25 18:44:25.9376[5][] DEBUG Liquesce.MainForm: Should now have a huge list of filePaths
2011-02-25 18:44:31.7564[1][] ERROR Program: =====================================================================
2011-02-25 18:44:31.7720[1][] ERROR Program: File Re-opened: 25/02/2011 8:44:31 AM
2011-02-25 18:44:31.8812[1][] DEBUG Liquesce.MainForm: Create the root node.
2011-02-25 18:44:31.8812[1][] DEBUG Liquesce.MainForm: Now we need to add any children to the root node.
2011-02-25 18:44:31.8812[1][] DEBUG Liquesce.MainForm: Start with drives if you have to search the entire computer.
2011-02-25 18:44:31.8812[1][] DEBUG Liquesce.MainForm: C:\
2011-02-25 18:44:31.8968[1][] DEBUG Liquesce.MainForm: D:\
2011-02-25 18:44:31.8968[1][] DEBUG Liquesce.MainForm: E:\
2011-02-25 18:44:31.8968[1][] DEBUG Liquesce.MainForm: F:\
2011-02-25 18:44:31.8968[1][] DEBUG Liquesce.MainForm: G:\
2011-02-25 18:44:31.8968[1][] DEBUG Liquesce.MainForm: H:\
2011-02-25 18:44:31.8968[1][] DEBUG Liquesce.MainForm: I:\
2011-02-25 18:44:31.8968[1][] DEBUG Liquesce.MainForm: J:\
2011-02-25 18:44:31.8968[1][] DEBUG Liquesce.MainForm: K:\
2011-02-25 18:44:31.8968[1][] DEBUG Liquesce.MainForm: L:\
2011-02-25 18:44:31.8968[1][] DEBUG Liquesce.MainForm: M:\
2011-02-25 18:44:31.8968[1][] DEBUG Liquesce.MainForm: N:\
2011-02-25 18:44:31.8968[1][] DEBUG Liquesce.MainForm: O:\
2011-02-25 18:44:31.9124[1][] DEBUG Liquesce.MainForm: X:\
2011-02-25 18:44:31.9124[1][] INFO Liquesce.MainForm: Removing the existing DOKAN drive as this would cause confusion ! [X:\]
2011-02-25 18:44:31.9124[1][] DEBUG Liquesce.MainForm: Z:\
2011-02-25 18:44:31.9124[1][] DEBUG Liquesce.MainForm: Remove the placeholder node.
2011-02-25 18:44:33.6284[1][] ERROR Program: File Closing
2011-02-25 18:44:33.6284[1][] ERROR Program: =====================================================================
2011-02-25 18:44:50.0397[1][] INFO Liquesce.MainForm: Didn't go bang so stop
2011-02-25 18:44:50.0397[1][] INFO Liquesce.MainForm: Send the new details
2011-02-25 18:44:50.0553[1][] INFO Liquesce.MainForm: Now start, may need a small sleep to allow things to settle
2011-02-25 18:45:08.0577[1][] ERROR Program: File Closing
2011-02-25 18:45:08.0577[1][] ERROR Program: =====================================================================
2011-02-25 18:46:00.0578[1][] ERROR Program: =====================================================================
2011-02-25 18:46:00.0734[1][] ERROR Program: File Re-opened: 25/02/2011 8:46:00 AM
2011-02-25 18:46:00.2138[1][] DEBUG Liquesce.MainForm: Create the root node.
2011-02-25 18:46:00.2138[1][] DEBUG Liquesce.MainForm: Now we need to add any children to the root node.
2011-02-25 18:46:00.2138[1][] DEBUG Liquesce.MainForm: Start with drives if you have to search the entire computer.
2011-02-25 18:46:00.2138[1][] DEBUG Liquesce.MainForm: C:\
2011-02-25 18:46:00.2138[1][] DEBUG Liquesce.MainForm: D:\

I do see this throughout the log though: (Y and Z are mapped drives, one is wireless, so quite slow to start)

2011-02-26 17:59:35.9329[1][] ERROR Program: File Closing
2011-02-26 17:59:35.9329[1][] ERROR Program: =====================================================================
2011-02-27 06:25:36.8453[1][] ERROR Program: =====================================================================
2011-02-27 06:25:36.8453[1][] ERROR Program: File Re-opened: 26/02/2011 8:25:36 PM
2011-02-27 06:25:36.9857[1][] DEBUG Liquesce.MainForm: Create the root node.
2011-02-27 06:25:36.9857[1][] DEBUG Liquesce.MainForm: Now we need to add any children to the root node.
2011-02-27 06:25:36.9857[1][] DEBUG Liquesce.MainForm: Start with drives if you have to search the entire computer.
2011-02-27 06:25:36.9857[1][] DEBUG Liquesce.MainForm: C:\
2011-02-27 06:25:37.0013[1][] DEBUG Liquesce.MainForm: D:\
2011-02-27 06:25:37.0013[1][] DEBUG Liquesce.MainForm: E:\
2011-02-27 06:25:37.0013[1][] DEBUG Liquesce.MainForm: F:\
2011-02-27 06:25:37.0013[1][] DEBUG Liquesce.MainForm: G:\
2011-02-27 06:25:37.0013[1][] DEBUG Liquesce.MainForm: H:\
2011-02-27 06:25:37.0013[1][] DEBUG Liquesce.MainForm: I:\
2011-02-27 06:25:37.0013[1][] DEBUG Liquesce.MainForm: J:\
2011-02-27 06:25:37.0013[1][] DEBUG Liquesce.MainForm: K:\
2011-02-27 06:25:37.0013[1][] DEBUG Liquesce.MainForm: L:\
2011-02-27 06:25:37.0013[1][] DEBUG Liquesce.MainForm: M:\
2011-02-27 06:25:37.0013[1][] DEBUG Liquesce.MainForm: N:\
2011-02-27 06:25:37.0013[1][] DEBUG Liquesce.MainForm: O:\
2011-02-27 06:25:37.0169[1][] DEBUG Liquesce.MainForm: X:\
2011-02-27 06:25:37.0169[1][] INFO Liquesce.MainForm: Removing the existing DOKAN drive as this would cause confusion ! [X:\]
2011-02-27 06:25:37.0169[1][] DEBUG Liquesce.MainForm: Y:\
2011-02-27 06:25:37.0169[1][] ERROR Liquesce.MainForm: StartTree Threw:  System.IO.IOException: The specified network name is no longer available.

   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.__Error.WinIODriveError(String driveName, Int32 errorCode)
   at System.IO.DriveInfo.get_DriveFormat()
   at Liquesce.MainForm.FillInDirectoryType(TreeNode parentNode, DriveInfo di)
   at Liquesce.MainForm.StartTree()
2011-02-27 06:25:38.7173[5][] DEBUG Liquesce.MainForm: Should now have a huge list of filePaths
2011-02-27 06:26:16.0014[1][] ERROR Program: File Closing
2011-02-27 06:26:16.0014[1][] ERROR Program: =====================================================================

The other logs don't have anything useful in them:

LiquesceSvc0..4.log: Nothing, these have been reset and only show entries from today.
LiquesceTray: (Missing "File Closing" in a couple of places - when the BSOD occurred)

2011-02-25 12:24:30.4737[1][] ERROR LiquesceTray.Program: File Re-opened: 25/02/2011 2:24:30 AM
2011-02-25 12:25:06.0574[1][] ERROR LiquesceTray.Program: File Closing
2011-02-25 12:25:06.0574[1][] ERROR LiquesceTray.Program: =====================================================================
2011-02-25 12:26:19.9604[1][] ERROR LiquesceTray.Program: =====================================================================
2011-02-25 12:26:19.9804[1][] ERROR LiquesceTray.Program: File Re-opened: 25/02/2011 2:26:19 AM
2011-02-25 18:09:44.1520[1][] ERROR LiquesceTray.Program: =====================================================================
2011-02-25 18:09:44.1820[1][] ERROR LiquesceTray.Program: File Re-opened: 25/02/2011 8:09:44 AM
2011-02-25 18:44:10.0788[1][] ERROR LiquesceTray.Program: =====================================================================
2011-02-25 18:44:10.0988[1][] ERROR LiquesceTray.Program: File Re-opened: 25/02/2011 8:44:10 AM
2011-02-25 18:46:42.2211[1][] ERROR LiquesceTray.Program: File Closing
2011-02-25 18:46:42.2211[1][] ERROR LiquesceTray.Program: =====================================================================
2011-02-25 18:47:55.8960[1][] ERROR LiquesceTray.Program: =====================================================================
2011-02-25 18:47:55.9360[1][] ERROR LiquesceTray.Program: File Re-opened: 25/02/2011 8:47:55 AM
2011-02-26 10:52:29.2900[1][] ERROR LiquesceTray.Program: File Closing

 

Feb 26, 2011 at 11:46 PM

Just one more thing before I finish up my preliminary testing for the week...

I've noticed that as you "drill down" through my media sub-directories, ones that have many files and are "further down" the structure, take much-much longer to display in Explorer.

This is on my "bare" Win7 Home machine freshly rebooted (it's an old P4 3.0GHz with loads of memory, but for file serving it's never been terribly slow) but I can see the LiquesceSvc.exe use heaps of CPU for quite a few seconds (a long time for a ~500 file sub-directory) around these slow areas.

On that machine it's not really been a huge problem, but when I use the network share and do the same navigation through my files, the CPU never goes high (perhaps limited by the kernel/share-service) but it takes an obscene amount of time to show files remotely!

The worst thing here is, some very deep levels of directories do not show up all files, and I think it's because it's timing out - although from the one subdir which reliably fails to show all files - it's always stopped on the same last filename.  Shows files named a.. to n.. but none from o.. onwards.

I picked this up from my backup software, which said there's a bunch of files that need to be copied - but when I looked they were already there - although directly on the machine it took some time to drill down to see them.

Looking in the log, I can see Liquesce does have slightly different output when looking at direct and share subdir navigations, but it always says it's found the same 494 files.  There's no events in the event log which suggest a timeout occured on the bad subdir though - no errors at all, even from Explorer.

Coordinator
Feb 27, 2011 at 8:39 AM
Jaso wrote:

I've noticed that as you "drill down" through my media sub-directories, ones that have many files and are "further down" the structure, take much-much longer to display in Explorer.

If you have Debug logging on then it is dumping out a lot of information. This will slow things down a lot; especially for a lot of files

Feb 27, 2011 at 10:47 AM
Edited Feb 27, 2011 at 11:14 AM

Ok, I figured it was worth trying with the logs set to Warn (I assume that's the best setting for performance, the "Trace" hint said it will slow things down more.)

Although, having looked at the logs, I didn't expect it to make too much difference (I know the machine is only a P4 3.0GHz, but it's got fast sata drives and is quite snappy for anything which isn't CPU bound.  I/O for a few hundred lines of logging shouldn't soak up that much CPU!)

I verified that the logs contained much less information, but I only saw a moderate decrease in CPU usage, could be as much as 1/3 less, but no more.  So it is still very slow.  For a comparison, I checked the properties on my 'other' media folder which is much higher up the directory tree and is quite "flat" in that respect (the Explorer properties window which calculates how many files/folders there are and how much disk space they take up - not the properties on the drive itself which only reports used/free space) and it only took about 2 times as long to calculate 8800 files / 6TB.  Maybe 5 seconds.  So to take ~3 or more seconds to show a single sub-directory with 500 files in it, and for the CPU to shoot up for all that time, I'd have to say something funny is going on.  I should add, deep directory structures with only 1 or 2 files is still quite fast to display - so it's not liquesce checking through all the other drives which is causing the delay.

Now, onto that P4 3.0GHz shared drive, accessed from another PC (my quad core 2.8GHz, which has a very fast SSD boot drive and oodles more memory) and drilling down the shared drive still takes forever!  It's a matter of click and read "war and peace".  Ok, maybe it's only 60~120 seconds each click, but most folders I click through only has a handful of files, a couple with over a hundred, and when I get to the problematic one deep down with ~500 files - it's still not showing any more than up to "N" in the filelist over the network share.

I'll attempt to post another message containing a list of the files in question: (if you pass it through a C# program which creates the files dummy filled with however many 0x00 bytes are shown, you can test it yourself!)

Coordinator
Feb 27, 2011 at 12:04 PM

Thanks for the further research and data. This all helps with trying to get this to be a useful application :-)

Jaso wrote:
I'll attempt to post another message containing a list of the files in question: (if you pass it through a C# program which creates the files dummy filled with however many 0x00 bytes are shown, you can test it yourself!)

I've moved your listing into the folowing Issue
http://liquesce.codeplex.com/workitem/8424
Please add more details to that if you find them

Feb 28, 2011 at 6:06 AM
Edited Feb 28, 2011 at 6:07 AM

Well, it seems you are somewhat off the hook!  (Take that as a bit of a joke, I was never holding you to any sort of account.)

I just attempted to copy those listed files over to a "mirror" DOKAN drive, his sample app., derived from a folder on my C: and it also doesn't show all the files when shared with another Win 7 Home x86 machine.  (But it doesn't take forever to show the 397 odd files which are shown though!)

All machines in this test were different to the ones before, none have had Liquesce or FlexRaid on them before - only DOKAN V0.6 was freshly installed on the server (actually a Win 7 Basic x86) in the test.

The SetFileTime did however work as is expected by my backup software - at least on a small set of files I tried in the root with two subdirs only.  I'll have to see if I can set up a more complex testcase with the "mirror" sample for this...  I did try liquesce again with another single file copy, but it still didn't correctly set the time.  That was deep within my media directory structures though.  If I can get it to fail in DOKAN mirror, I'll report back on what I had to do.

Feb 28, 2011 at 6:25 AM
Edited Feb 28, 2011 at 6:50 AM

More strangness, something I wasn't worried too much about until just now, when it happened every few "refreshes" in my backup software which uses:

_findfirst, _findnext & _findclose

I did notice some directories "in total" would show up sometimes (as needs to be backed up) in Liquesce...  But this mirror app. quite often shows all the files as pending for backup - then refresh it, and they're gone again!  (I.E. it sees them again.)

It would seem that DOKAN over network shares sometimes dies on a directory traversal.  Interestingly I've now remembered that I've seen Explorer show a blank dir too sometimes, then refreshed to see all the files.

Oh dear.

EDIT: Seems to settle down after a while, but then update/delete 1 file in DOKAN mirror and bam!  At random times it can't read all the files using those API calls.

Feb 28, 2011 at 9:11 AM

Sorry to intervene, but I wonder if all those Dokan issues, plus the seemingly lack of "fire" from Dokan master developer, signals for some other direction.

Coordinator
Feb 28, 2011 at 10:56 AM
NLS wrote:
all those Dokan issues, plus the seemingly lack of "fire" from Dokan master developer, signals for some other direction.

I tried and the only thing that kept coming up was to use the CallbackFS, which is costly, and would prevent opensource.

The other options have been image style loaders but that requires moving the data off the HDD's into the image, Much like WHS DE stuff.

It might be worth another scan to see if more "Installable File System with User Mode/Space callbacks" are being developed ??

Mar 1, 2011 at 1:01 AM
Edited Mar 1, 2011 at 1:24 PM

Some final feedback for you (can't really continue now):

No BSOD yet, given that I shut down the Doken drive(s - Mirror/Liquesce) before Hibernate - but I'm still not willing to say 100% that it is Dokan, I do have a new USB dongle plugged into that machine for wireless - though what it may be doing getting in the way of opening a file in explorer I don't know, more time will tell.

SetFileTime alone works as is expected on Liquesce!  It's the SetFileAttributes which is setting the date back to "now" straight away afterwards - this isn't happening on Mirror, it's working properly I think - remember not too much testing has been done here, maybe attributes are not implemented there?

Creating directories in Liquesce isn't working like in Mirror, my backup software fails to create them at all!  Explorer creates them but on a rename "moves" them into a new sub-dir created with the full-old-path!  (Given: X:\foobar, create: X:\foobar\New Folder, rename it to "test" and get X:\foobar\foobar\test)  (EDIT: That's on a shared drive - not performed locally.)

Coordinator
Mar 5, 2011 at 10:23 AM
Jaso wrote:
1) SetFileTime alone works as is expected on Liquesce! 
2) It's the SetFileAttributes which is setting the date back to "now" straight away afterwards - this isn't happening on Mirror, it's working properly I think - remember not too much testing has been done here, maybe attributes are not implemented there?

1) This uses the current open handle (Or opens a handle) to the file and then uses PInvoke to get to the win32 function:

      private static extern bool SetFileTime(SafeFileHandle hFile, ref long lpCreationTime, ref long lpLastAccessTime, ref long lpLastWriteTime);

2) This uses the C# function

 File.SetAttributes(path, attr);

I'm not saying this is at fault, just that the code that finds the path might be the fault (It was all changed to incorporate the _backup / Priroty modes etc !)
It might be worth going back to "http://liquesce.codeplex.com/releases/view/52745" (Needs Dokan 0.5.3 to be installed first) to see if that solves this issue ?

Coordinator
Mar 5, 2011 at 10:26 AM
Jaso wrote:
Creating directories in Liquesce isn't working like in Mirror, my backup software fails to create them at all!  Explorer creates them but on a rename "moves" them into a new sub-dir created with the full-old-path!  (Given: X:\foobar, create: X:\foobar\New Folder, rename it to "test" and get X:\foobar\foobar\test)  (EDIT: That's on a shared drive - not performed locally.)

1) What "Mode" are you in ?

2) Can you please:

  • set the threads to 1
  • Logging to Trace
  • Create a new Issue
  • Add the log and the details to the new issue
Coordinator
Mar 6, 2011 at 8:13 AM
Jaso wrote:

I'm in "folder" mode, threads is already 1.  I'm using selective reading for your other points!, but here is the log-part of interest: (1 drive in Liquesce, which is empty and called "N:", try to copy 1 file in "X:\Debug\vc60.pdb" Liquesce drive from the backup source...)

The backup software attempts to create the file (with full path) and if the CreateFile returns an invalid handle (I.E. fails) checks GetLastError for ERROR_PATH_NOT_FOUND and attempts to do a CreateDirectory for "X:\Debug" - then I stopped the Liquesce service:

The details have been added this issue - http://liquesce.codeplex.com/workitem/7097

Coordinator
Mar 6, 2011 at 8:20 AM
Jaso wrote:
I'm in "folder" mode, threads is already 1.
Re: Attributes:

here's the log from when it really happens by using another test harness for settime/setattributes: (I put a Sleep (5000) between the CloseHandle(..) and SetFileAttributes(..) - so at 40secs past 11:21 it changes the modified time, then at 45secs past it does the SetFileAttributes alone and finishes.  Not shown in this log, but if I refresh Explorer a few times within those 5 seconds, the time I wanted to set shows correctly, but then changes to 'now' after the 5 seconds...)


2011-03-06 11:21:40.3886[11][] TRACE LiquesceSvc.LiquesceOps: SetFileAttributes IN DokanProcessId[4]
2011-03-06 11:21:40.3886[11][] DEBUG LiquesceSvc.Roots: GetPath from [\a.txt] found [N:\a.txt]
2011-03-06 11:21:40.3886[11][] TRACE LiquesceSvc.LiquesceOps: SetFileAttributes OUT
2011-03-06 11:21:40.4042[11][] TRACE LiquesceSvc.LiquesceOps: SetFileTime IN DokanProcessId[4]


2011-03-06 11:21:45.3962[11][] TRACE DokanNet.Proxy: CreateFileProxy IN  rawFileName[84244684], rawAccessMode[1048960], rawShare[7], rawCreationDisposition[3], rawFlagsAndAttributes[0]
2011-03-06 11:21:45.3962[11][] DEBUG LiquesceSvc.LiquesceOps: CreateFile IN filename [\a.txt], rawAccessMode[1048960], rawShare[7], rawCreationDisposition[3], rawFlagsAndAttributes[0], ProcessId[4]
2011-03-06 11:21:45.3962[11][] DEBUG LiquesceSvc.Roots: GetPath from [\a.txt] found [N:\a.txt]
2011-03-06 11:21:45.3962[11][] TRACE LiquesceSvc.LiquesceOps: CreateFile OUT actualErrorCode=[0] context[4]
2011-03-06 11:21:45.3962[11][] TRACE LiquesceSvc.LiquesceOps: GetFileInformation IN DokanProcessId[4]
2011-03-06 11:21:45.3962[11][] TRACE LiquesceSvc.LiquesceOps: info.refFileHandleContext [4]
2011-03-06 11:21:45.3962[11][] DEBUG LiquesceSvc.Roots: GetPath from [\a.txt] found [N:\a.txt]
2011-03-06 11:21:45.3962[11][] TRACE LiquesceSvc.LiquesceOps: GetFileInformation OUT Attributes[Normal, Offline, NotContentIndexed] Length[3] dokanReturn[0]
2011-03-06 11:21:45.3962[11][] TRACE LiquesceSvc.LiquesceOps: GetFileInformation IN DokanProcessId[4]
2011-03-06 11:21:45.3962[11][] TRACE LiquesceSvc.LiquesceOps: info.refFileHandleContext [4]
2011-03-06 11:21:45.3962[11][] TRACE LiquesceSvc.LiquesceOps: GetFileInformation OUT Attributes[Normal, Offline, NotContentIndexed] Length[3] dokanReturn[0]
2011-03-06 11:21:45.3962[11][] TRACE LiquesceSvc.LiquesceOps: SetFileAttributes IN DokanProcessId[4]
2011-03-06 11:21:45.3962[11][] DEBUG LiquesceSvc.Roots: GetPath from [\a.txt] found [N:\a.txt]
2011-03-06 11:21:45.3962[11][] TRACE LiquesceSvc.LiquesceOps: SetFileAttributes OUT
2011-03-06 11:21:45.3962[11][] TRACE LiquesceSvc.LiquesceOps: SetFileTime IN DokanProcessId[4]
2011-03-06 11:21:45.3962[11][] TRACE LiquesceSvc.LiquesceOps: info.refFileHandleContext [4]
2011-03-06 11:21:45.3962[11][] TRACE LiquesceSvc.LiquesceOps: SetFileTime OUT
2011-03-06 11:21:45.3962[11][] TRACE LiquesceSvc.LiquesceOps: Cleanup IN DokanProcessId[4] with filename [\a.txt]
2011-03-06 11:21:45.3962[11][] TRACE LiquesceSvc.LiquesceOps: CloseAndRemove info.refFileHandleContext [4]
2011-03-06 11:21:45.4118[11][] TRACE LiquesceSvc.LiquesceOps: CloseAndRemove [N:\a.txt] info.refFileHandleContext[4]
2011-03-06 11:21:45.4118[11][] TRACE LiquesceSvc.LiquesceOps: Cleanup OUT
2011-03-06 11:21:45.4118[11][] TRACE LiquesceSvc.LiquesceOps: CloseFile IN DokanProcessId[4]
2011-03-06 11:21:45.4118[11][] TRACE LiquesceSvc.LiquesceOps: CloseFile OUT
2011-03-06 11:21:46.4102[11][] TRACE DokanNet.Proxy: CreateFileProxy IN  rawFileName[84244684], rawAccessMode[1048705], rawShare[7], rawCreationDisposition[3], rawFlagsAndAttributes[0]
2011-03-06 11:21:46.4102[11][] DEBUG LiquesceSvc.LiquesceOps: CreateFile IN filename [\], rawAccessMode[1048705], rawShare[7], rawCreationDisposition[3], rawFlagsAndAttributes[0], ProcessId[3076]
2011-03-06 11:21:46.4102[11][] DEBUG LiquesceSvc.Roots: GetPath from [\] found [N:]
2011-03-06 11:21:46.4102[11][] TRACE LiquesceSvc.LiquesceOps: OpenDirectory IN DokanProcessId[3076]
2011-03-06 11:21:46.4102[11][] TRACE LiquesceSvc.LiquesceOps: Try and OpenDirectory from [N:\]
2011-03-06 11:21:46.4102[11][] TRACE LiquesceSvc.LiquesceOps: Directory.Exists[N:\] Adding details
2011-03-06 11:21:46.4102[11][] TRACE LiquesceSvc.LiquesceOps: OpenDirectory OUT. dokanError[0]
2011-03-06 11:21:46.4102[11][] TRACE LiquesceSvc.LiquesceOps: CreateFile OUT actualErrorCode=[0] context[4]
2011-03-06 11:21:46.4102[11][] DEBUG LiquesceSvc.LiquesceOps: FindFiles IN [\], pattern[a.txt]
2011-03-06 11:21:46.4102[11][] TRACE LiquesceSvc.LiquesceOps: AddFiles IN path[N:\] pattern[a.txt]
2011-03-06 11:21:46.4102[11][] TRACE LiquesceSvc.Roots: Adding [\a.txt] to [N:\a.txt]
2011-03-06 11:21:46.4102[11][] DEBUG LiquesceSvc.LiquesceOps: FindFiles OUT [found 1]
2011-03-06 11:21:46.4102[11][] TRACE LiquesceSvc.LiquesceOps:
a.txt
 
2011-03-06 11:21:46.4102[11][] TRACE LiquesceSvc.LiquesceOps: Cleanup IN DokanProcessId[3076] with filename [\]
2011-03-06 11:21:46.4102[11][] TRACE LiquesceSvc.LiquesceOps: Cleanup OUT
2011-03-06 11:21:46.4102[11][] TRACE LiquesceSvc.LiquesceOps: CloseFile IN DokanProcessId[3076]
2011-03-06 11:21:46.4102[11][] TRACE LiquesceSvc.LiquesceOps: CloseFile OUT

From the log I would assume that you BAckup application is DokanProcessId[4], and explorer is 3076 ?
Seems like for every Set Attirbutes, there is a SetFileTime being called immediately afterwards from Process 4:
Are you sure the 2nd one is doing the correct time stamp ?
Also there is a process opening the file, which will also modify the last accessed timestamp as well.

 

Mar 6, 2011 at 10:02 AM
Edited Mar 6, 2011 at 10:07 AM

I just looked at your code, and I can't see how you *might* be passing in a NULL, if a NULL is needed for any of the 3 dates that can be set on a file.

Coordinator
Mar 8, 2011 at 4:54 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Coordinator
Mar 8, 2011 at 5:00 PM
Edited Mar 8, 2011 at 7:15 PM

Like the Silly "automatic" not very polite message states above: The SetFileTime Problem and details have been copied to this workItem "http://liquesce.codeplex.com/workitem/8488"

Edit: Fixed (Probably :-) Changeset 62393
And I found this from a long time ago http://code.google.com/p/dokan/issues/detail?id=177

Edit 2: "http://liquesce.codeplex.com/releases/view/62221"

Mar 10, 2011 at 3:33 AM

Good stuff...  That's working well now.

Coordinator
Mar 10, 2011 at 5:13 PM
jaso wrote:
Good stuff...  That's working well now.

Thanks for the code review that pointed out the "flaw in the logic"

What I have not been able to do yet - is reproduce the Copy fault you where having..
Is that still happening ?
Does it only occurr when performing the copy over the share ?

Mar 10, 2011 at 9:43 PM

Ok, more testing and MessageBox'es in the code and this seems to be the problem:

On return, I check if the CreateFile worked, if not I check for ERROR_PATH_NOT_FOUND and continue to create the path requred (works on normal drives and shares to normal drives.)

In this case Liquesce seems to be passing back a "GetLastError" value of 87 though, which is ERROR_INVALID_PARAMETER from what I can tell.  This makes the backup software abort the copy and continue with the next file.

Coordinator
Mar 11, 2011 at 6:02 PM
jaso wrote:
On return, I check if the CreateFile worked, if not I check for ERROR_PATH_NOT_FOUND and continue to create the path requred (works on normal drives and shares to normal drives.)
In this case Liquesce seems to be passing back a "GetLastError" value of 87 though, which is ERROR_INVALID_PARAMETER from what I can tell.  This makes the backup software abort the copy and continue with the next file.

Thanks for the excellent research - it all helps.

I have Moved and updated the Issue with the details you included here for the Directory Rename http://liquesce.codeplex.com/workitem/7097

I have Moved Updated the BSOD data to http://liquesce.codeplex.com/workitem/8428