SMB share scanning - can't handle whitespace

[GoogleCodeExporter]

What steps will reproduce the problem?
1.Scanning an SMB share with whitespaces in the diretory names eg \\1.1.1.1\My 
Documents

2.Get an error of "Systems to Scan" has invalid character

What is the expected output? What do you see instead?

1. Expected the scan to run with whitespace or some kind of substitute like %20 
etc. instead throws up the "Systems to Scan" has invalid character issue.

What version of the product are you using? On what operating system?

1. Applies to version 0.5

Original issue reported on code.google.com by andy99...@gmail.com on 23 Aug 2012 at 3:03

[GoogleCodeExporter]

I can reproduce this in 0.5. This should not be a bug in 0.4.4, so I recommend 
downgrading until 0.5.1 is released. Thanks for reporting this!

Original comment by andrew.O...@gmail.com on 24 Aug 2012 at 1:04

• Changed state: Accepted

[GoogleCodeExporter]

Thanks, any work arounds you can think of? heres what we are doing at the 
moment, might be useful to someone:

For us we are trying to scan the following location for example:

\\1.1.1.1\share\staff share

1. Edit the scanning profile, in the Directories section click "Only scan the 
following directories (recursive)" and add in the share direcotry names you 
want to scan (the ones with the spaces) ie "staff share" in this case.

2. Start the scan in the root dir ie: \\1.1.1.1\share leaving off the 
directories with blank spaces - this works for us for the moment not sure if it 
takes longer maybe you can advise? but seems to do the trick.

Also while I'm thinking about it, are there plans to add in a multithreaded 
approach to the SMB scanning?

Original comment by andy99...@gmail.com on 24 Aug 2012 at 9:00

[GoogleCodeExporter]

There are no workarounds for 0.5. The bug was introduced in 0.5, so downgrading 
to 0.4.4 will fix it. I will be releasing 0.5.1 sometime next week to address 
this.

As far as multithreading goes, you can scan multiple, separate shares at the 
same time. However, if you are just scanning one share, it currently will just 
use one thread. If I used more than one thread when scanning just one share, it 
would degrade network performance -- any performance gained by multithreading 
would likely be lost by slower network transfers.

Original comment by andrew.O...@gmail.com on 24 Aug 2012 at 12:07

[GoogleCodeExporter]

This has been fixed in OpenDLP 0.5.1, which was just released. Thanks for 
reporting this!

Original comment by andrew.O...@gmail.com on 28 Aug 2012 at 12:48

• Changed state: Done