google drive not working

[viciousviper]

google drive not working

[viciousviper]

Hi lahela223,

sorry to hear that all is not working right for you.

Could you please be more specific with your issues, preferrably by quoting the precise steps you took, so that I may try to reproduce them on my environment?

When you're saying

google drive is failing if there are multiple files with same name on root

what exactly do you mean?
I just checked with a Google Drive root directory containing two files named "TheFile.txt" and "tHEfILE.txt" - which wouldn't even considered to be two different files on a local NTFS volume - and was able to edit each one of the separately using notepad.exe. It is true that Windows Explorer tends to muck up its display, but after an explicit refresh I am able to see (and use) both files.

Also, regarding

not able to copy any file in drive it says drive full.

I didn't have any problems with copying multiple files into a Google Drive volume from a different volume - or copy a file inside the Google Drive root directory. Actually, this is how I created the file "tHEfILE.txt" in the first place.

Please report the Gateway variant and assembly versions you are using.
I carried out my tests on IgorSoft.CloudFS.Gateways.GDrive in a pre-1.0.11-beta version not quite ready for release - so I might be missing a bug that is present in an older version.

Cheers
vv

[psxvoid]

Hello lahela223 and viciousviper,

I also having the same issue in the latest version (1.0.11-beta). In a root folder of my google drive I have two folders named "Work" (but they have different Ids). ArgumentException occur during child folder enumeration inside:
DokanCloudFS\CloudDirectoryNode.csGetChildItems

To be more specific - during .ToDictionary(x => x.Name); call.

I have used a very dirty workaround to make it work for me but it is may require to consider changing CloudDirectoryNode.children type from Dictionary to Lookup. Another way - is to change the behavior of Google Drive Provider. May be.

I would work on it further with your guidance.

[viciousviper]

Hi @psxvoid,

thanks for reporting this condition.
I have to admit that configurations of several identically named cloud items inside a cloud directory have so far been out of scope for DokanCloudFS.
You are right in assuming that the internally used Dictionary will choke on duplicate item names - and that this could be remedied by switching to a Lookup data structure on a technical level. However, this is not the whole truth.
So far, DokanCloudFS converts cloud item names directly into FileSystemInfo names exposed to the virtual Windows file system - and this a much more inconvenient place where duplicate names (even duplicates ignoring case) will cause problems.
Therefore, a robust scheme for duplicate name handling would have to choose unique name replacements for one (or both) identically named cloud items. For N identically named cloud items, this would mean choosing unique name replacements for N-1 (or all N) items.

What kind of file/directory names would you expect to see on the Windows filesystem side, and how would you expect to distinguish between them?

[psxvoid]

Hi @viciousviper,

Thanks for sharing such interesting project.

Regarding the naming scheme - this is how google drive client for windows handles the issue:

1. If there are two "Scripts" folders, the first will be named "Scripts". The second one "Scripts (1)".
2. If there are two "Scripts" folders and a one "Scripts (1)". The first will be named "Scripts", the second one - "Scripts (1)" (originally "Scripts"), the third one - "Scripts (2)" (originally "Scripts (1)"):

So, it is possible to name them differently, e.g. "Scripts[1] formerly Scripts". Also there is could be another issue - with renaming such folders.

So, may be it worth to introduce another optional field for CloudItemNode like "Alias". Or a required "Id". By the way, apps like "ExpanDrive" or "NetDrive2" just ignore duplicate names:

[viciousviper]

Yeah, the "Scripts"-"Scripts (1)"-"Scripts (2)" scheme is pretty much the standard behavior of Windows Explorer when you copy a preexisting file without renaming it.

However, in your scenario it is not quite as clear which of the multiple instances should be regarded as the "original" and which are the "copies" - and how the copies should be ordered. In general, even a distinction by creation/modification date may not lead to unique results. Displaying just one of the several identically named items does not feel right, either. After all - which one should be chosen to represent the set, and would it not confuse a user if he/she removed/renamed the item and a different instance popped up from nowhere?

Your suggestion of additional file attributes like "Alias" or "Id" cannot work, alas, because the System.IO.FileSystemInfo data structure is not extensible.

I could certainly suppress non-unique items entirely - but this does not appear to be the intention of the original poster. It would avoid the Exception, though.

[psxvoid]

Yeah, it is some kind of weird. Popping up folders sounds not user friendly and generally should be avoided. Except exceptional cases like this one. Probably, the order of copies doesn't matter because the main purpose of this feature could be the ability to see all data inside a "gateway" provider. The order may be defined during files\folder enumeration.

Regarding "Alias" - would it be possible to pass the alias (when it is not null) instead of a file name to System.IO.FileSystemInfo data structure? If it unique then we might be able to get the "original" value using a "conflict" dictionary. It is not perfect but it may work.

Another possible naming scheme might be "Conflict name [N] - <original_file_name>". We can use something similar to the following algorithm during files\folders enumeration (pseudo code):

conflictNumber = 0;
conflictDictionary = new Dictionary();
...
If file with the same name is already enumerated then 
{
    set name to "Conflict name " + conflictNumber + " - " + name
    add name to conflictDictionary
}