EldoS | Feel safer!

Software components for data protection, secure storage and transfer

TElZipReader cannot unzip to UNC path?

Also by EldoS: BizCrypto
Components for BizTalk® and SQL Server® Integration Services that let you securely store and transfer information in your business automation solutions.
#30355
Posted: 08/14/2014 07:34:45
by Eugene Mayevski (EldoS Corp.)

Thank you for details, we'll try to reproduce the issue the way you described. Hope to get some results later today or tomorrow.


Sincerely yours
Eugene Mayevski
#30356
Posted: 08/14/2014 07:37:32
by Eugene Mayevski (EldoS Corp.)

Quote
Peter Palotas wrote:
I ran ProcMon to see what the program was doing and it seems to call CreateFile with the arguments "C:\MyMachine\temp\output\file.txt" instead of "\\MyMachine\temp\output\file.txt" as it should. So for some reason SecureBlackbox.


It's the way the path is translated before it reaches the filesystem. This is ok.

Quote
Peter Palotas wrote:
Debugging a little using the custom TElDiskFileSystemAdapter from the sample you suggested it appears that the first line in DoOpenFile() calls AdjustPath on the path, and this removes one of the leading backslashes, hence the path used will be "\MyMachine\temp...", which of course will not be treated as an UNC path.


Are you sure that the backslash is removed by the method and not in IDE's evaluator when the value is displayed? The backslash is an escape character and IDE in some operations translates the escape sequences (and sometimes does this wrong).


Sincerely yours
Eugene Mayevski
#30357
Posted: 08/14/2014 07:40:57
by Eugene Mayevski (EldoS Corp.)

I think I understand what can "remove" the first backslash, however in version 11 the code was different and the problem existed anyway. So the real problem is somewhere else.


Sincerely yours
Eugene Mayevski
#30358
Posted: 08/14/2014 07:49:37
by Peter Palotas (Basic support level)
Joined: 11/01/2012
Posts: 49

The backslash is indeed removed. The path starts with two backslashes, and the RealPath after the call to AdjustPath starts with only one backslash.

I am also quite sure that the UNC path should not be translated to "C:\..." in the call to CreateFile. As a test I created a file in the same UNC path using File.WriteAllText() first, and the logs from Process monitor shows the correct UNC paths for those calls, followed by the "C:\..." when it comes to the EldoS functions.

I've attached the relevant part of the log from ProcMon (as a CSV file renamed to .txt) that illustrates this. The "hello.txt" file is the one I create using File.WriteAllText(), and then the "MSMQ Send To VAN.ieo" is the first file that should be extracted from the archive using the TElZipReader.


[ Download ]
#30359
Posted: 08/14/2014 08:01:44
by Peter Palotas (Basic support level)
Joined: 11/01/2012
Posts: 49

A simpler way to reproduce the problem is just the following lines of code which in my case will return 103429 for the eldos call, while the "File.Create()" succeeds.

Code
SBDiskFSAdapter.TElDiskFileSystemAdapter adapter = new SBDiskFSAdapter.TElDiskFileSystemAdapter();
object fileHandle = null;
string filePath = @"\\icsws025\temp\myfile.txt";
int code = adapter.FileOpen(filePath, 4, TSBFileShareMode.ssmExclusive, ref fileHandle);
Console.WriteLine(code);
File.Create(filePath);
#30360
Posted: 08/14/2014 08:03:51
by Eugene Mayevski (EldoS Corp.)

If the path is (incorrectly) changed to "\icsws025\temp\output\" (with one backslash), this becomes the absolute path on the current drive. Then the OS expands such path to "C:\icsws025\temp\output\". This is the expected behavior as well.

Please hold on with experiments until the new build because we need to fix the problem with the leading backslash and it's only fixable by rebuild. We will make a build later today or tomorrow.


Sincerely yours
Eugene Mayevski
#30361
Posted: 08/14/2014 08:07:20
by Eugene Mayevski (EldoS Corp.)

Quote
Peter Palotas wrote:
A simpler way to reproduce the problem is just the following lines of code which in my case will return 103429 for the eldos call, while the "File.Create()" succeeds.


right, in version 12 it's due to broken AdjustPath/JoinPaths method. In version 11 this code should work but it doesn't for some users and the AdjustPath/JoinPaths method works correctly there.


Sincerely yours
Eugene Mayevski
#30362
Posted: 08/14/2014 08:19:49
by Peter Palotas (Basic support level)
Joined: 11/01/2012
Posts: 49

Yes, I tried with version 11 again, and then I don't see any access being made to the file I specified at all using ProcMon. So there is indeed something else that is the problem there, but as to what I have no idea without being able to debug into the FileOpen call.

Anyway, I will await your further tests and information.
#30368
Posted: 08/14/2014 14:07:12
by Eugene Mayevski (EldoS Corp.)

Let's continue in HelpDesk ( https://www.eldos.com/helpdesk/ ) please. I have created a new support ticket based on your above message. You will see your (and only your) support tickets by following this URL. You will also get e-mail notifications about updates related to your support ticket.


Sincerely yours
Eugene Mayevski
#30388
Posted: 08/17/2014 09:00:13
by Eugene Mayevski (EldoS Corp.)

For everyone's information - Build 12.0.258 seems to address all problems related to UNC paths.


Sincerely yours
Eugene Mayevski
Also by EldoS: BizCrypto
Components for BizTalk® and SQL Server® Integration Services that let you securely store and transfer information in your business automation solutions.

Reply

Statistics

Topic viewed 3063 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!