Locks up when invalid UNC folder compared
Locks up when invalid UNC folder compared
ExamDiff Pro v3.3 locks up when 'compare' window is shown with invalid UNC folder (e.g. \\BOGUS\MyShare). It doesn't even give me a chance to change the incorrect path; the programs locks up indefinetely and can't even be killed by TaskManager (Windows XP). Other than this problem, i've really enjoyed using ExamDiff.
thanks
thanks
I don't see it happening in 3.3 or 3.4 Beta. When I enter \\BOGUS\MyShare in the Compare dialog, I get the following error message on pressing Compare button:
Are there any other steps involved?
Code: Select all
---------------------------
ExamDiff Pro
---------------------------
File or directory \\BOGUS\MyShare does not exist
---------------------------
OK
---------------------------
psguru
PrestoSoft
PrestoSoft
Your correct. The remote folder existed at one time, but is no longer available (remote computer was turned off, etc). In my specific case, I use Exam Diff to update remote computers that I reach via a VPN. So not only is the computer not reachable, but the network is not reachable either when the VPN is not connected.
To add a little to the mystery, I must admit that after posting my diagnosis, I spotted a few unresponsive EDP taksbar icons. I think they were comparison windows already open before I started experimenting (even though Change Notification is always Do Not Monitor). I didn't give them more than 5 minutes or so. They offered no resistance to Windows 2000 task manager's kiss of death. After that I was unable to reproduce them.
Note that EDP seems to remove traces of crimes committed. Whether you cancel or exit after clicking away the error message, the history lists of first and second files and directories do not record the bogus paths. This is good, we don't want typos leading nowhere to clutter the history lists. However... after wildly playing around with multiple instances, several bogus paths are in my history now - in fact file comparison defaults to one. I say wildly because I failed to get any bogus path stored in history when following a reproducable sequence of starting and closing EDP sessions. What is going on here?
Note that EDP seems to remove traces of crimes committed. Whether you cancel or exit after clicking away the error message, the history lists of first and second files and directories do not record the bogus paths. This is good, we don't want typos leading nowhere to clutter the history lists. However... after wildly playing around with multiple instances, several bogus paths are in my history now - in fact file comparison defaults to one. I say wildly because I failed to get any bogus path stored in history when following a reproducable sequence of starting and closing EDP sessions. What is going on here?
Oink!zweinstein's question
In response to 'How does explorer react if you feed it the bogus UNC?':
It varies, sometimes it immediately tells me that the path is invalid, other times it hangs for several minutes, other times it hangs forever.
Its understandable that if I type in a bad address and hit Compare that EDP might hang for a while. But once that invalid UNC is the default, then EDP hangs when I first start it without even giving me a chance to change it.
My workaround for now is to always used mapped drives instead of UNC paths. EDP doesn't seem to have problem with mapped drives that are no longer valid.
It varies, sometimes it immediately tells me that the path is invalid, other times it hangs for several minutes, other times it hangs forever.
Its understandable that if I type in a bad address and hit Compare that EDP might hang for a while. But once that invalid UNC is the default, then EDP hangs when I first start it without even giving me a chance to change it.
My workaround for now is to always used mapped drives instead of UNC paths. EDP doesn't seem to have problem with mapped drives that are no longer valid.
I'm not sure. It's obviously hard to tell without knowing your steps, but wouldn't be "wildly"...However... after wildly playing around with multiple instances, several bogus paths are in my history now - in fact file comparison defaults to one. I say wildly because I failed to get any bogus path stored in history when following a reproducable sequence of starting and closing EDP sessions. What is going on here?
I'm also confused whether or not EDP froze/delayed for you when you used an invalid UNC path in the Compare dialog. Regardless, perhaps the following link will shed some light on the problem: http://www.sysinternals.com/blog/2005/0 ... oying.html
psguru
PrestoSoft
PrestoSoft
So you are saying that EDP hangs (indefinitely?) even before you get a chance to change a name, right? In other words, when you start EDP, it doesn't show up (indefinitely?), correct? If so, it sounds odd: nothing, as far as I can seen, in EDP code goes to verify file/directory existence when the application starts. Perhaps I'm missing something here.
BTW, is there a way to reproduce this problem outside of working with VPN?
BTW, is there a way to reproduce this problem outside of working with VPN?
psguru
PrestoSoft
PrestoSoft
On my system, the bogus default path doesn't cause any delay when starting EDP from the Start menu, not does selecting another bogus path from the history. There is no problem, only the odd fact that bogus paths are sometimes remembered but not when you look closely.
aaronp, what if you circumvent the selection dialog, e.g. select 2 files in Explorer and Compare them from the Explorer menu?
aaronp, what if you circumvent the selection dialog, e.g. select 2 files in Explorer and Compare them from the Explorer menu?