Write operations seem to be hanging

[epic0tix]

I am seeing odd behavior and was wondering if anyone else was as well,

When testing my CloudFS plugin, that was based heavily on the FILE plugin write operations are hanging and never completing.

anytime the content.CopyTo(stream) is being called the program hangs.

It appears that for some reason the Dokan stream is never actually getting copied to the GatherStream because assigned blocks is always empty and so GetAvailableBytes is coming back as 0.

As a sanity check I also attached the original untouched FILE plugin and had similar results.

has anything changed that could be affecting this ?

[viciousviper]

You're right - the latest changes that were introduced to support filesystems with "immutable" files (read: MEGA) seem to have broken something.
Please revert to v 1.0.4-alpha for the time being - I'll get to the root of this.

[epic0tix]

The crux of the problem seems to be that in Dokan Operations set allocation Size

            var context = (StreamContext)info.Context;
            context.Stream = scatterStream;

and the content is never copied from the Dokan context stream to the scatterStream so everything is blank :)

[viciousviper]

Could you please check if my latest checkin to the develop branch does any good for your problem?
I haven't quite gotten around to reproducing your observation with the call to SetAllocationSize(), however, there definitely was a bug in determining file sizes for encrypted files - which may account for your hangs in Stream.CopyTo().

With the fix applied I was able to write a ~12Mb binary file to a FILE based volume, verify its CRC while on the mounted volume and copy it back to a normal HD intact.

[epic0tix]

I will check however I should have clarified before I am using the library with the encryption key set to "" which, I understood, would bypass the encryption all together, I am wondering if this could also account for the problems I am seeing

[viciousviper]

You are correct in assuming that encryptionKey = string.Empty bypasses encryption.
I will doublecheck tonight that everything works as it should with encryption turned off.

BTW, do you access your mounted cloud volume through Windows Explorer or directly from .NET code?

My primary design goal for DokanCloudFS has been to enable cloud access for Windows Explorer, so there is a chance that not all code paths are covered for "raw" .NET - although this will definitely work for the CloudFS gateways.

[epic0tix]

I access the mounted cloud volume via windows Explorer,

I am still seeing issues with writes after the changes.

I wonder if the proxy file creation could be interfering as that seems to be a fairly recent change.

the reason I mentioned the SetAllocation is that I am seeing scenarios where Write is called before set allocation and as far as I can tell that written content would not end up in the scatterstream.

[viciousviper]

the reason I mentioned the SetAllocation is that I am seeing scenarios where Write is called before set allocation and as far as I can tell that written content would not end up in the scatterstream.

That's interesting. I've not seen this behavior so far. IIRC the only case where SetAllocationSize() is not called first is for small files (< 4kb) where the entire content is written in a single Write().

Do you have a specific scenario that I could try to reproduce, like

• do you write a single file/multiple files/a single folder with its files/nested folders?
• what size are the affected files?
• what filesystem type is the originating volume?
• what OS platform are you testing on?

[epic0tix]

I was testing with small files.. but in those cases the file save hangs.

[viciousviper]

Ok, bad habit. I just saw that your reply came between my original comment and my edits.
If you'd be so kind as to give me a couple more specifics of your scenario I'd be happy to look into this tonight.

[epic0tix]

Sorry about that.

My setup is windows 8.1 and windows 10
I am testing with large txt files and small txt files from notepad as that uses simple file io and and office documents such as doc and docx files which has a tendency to use overlapped io
file system I am writing to is NTFS
all files are affected.

I am using BTSYNC that is selectively syncing files from a remote share but as far as access goes all my reads and writes are local and I am not seeing file access issues.

[viciousviper]

Please verify if #9c11912 improves anything.

[epic0tix]

These are tests with small files.

1: So new file saving no longer hangs but the files are written to the disk and then immediately are removed

2: If you attempt to open an existing txt file and then attempt to save it an error is thrown as the driver attempts to use the original stream that only has read permissions

when using the file sample cloud disk saving a file now returns a permissions error

Attached are the two log files from my notepad test with my virtual drive "CloudShare" and the "File"
virtual drive

for this test I literally started the drive,
opened up notepad
typed "this is a test"
and then hit the close button at which point it asked if I wanted to save and I selected each of the drives named the file something like test.txt and attempted to save.

CloudShare Simple Text Save.txt
File Simple Text Save.txt

[viciousviper]

Thanks very much for this detailed report - I now understand the reason behind your observed errors much better.
To be frank, I haven't viewed the online editing use case as very important so far and rather focused on a backup/sync scenario.