File Comparator Residual Thread Left Open?

[therube]

File Comparator Residual Thread Left Open? At least for a period of time?

Not sure if this is a Salamander issue or not (& I'm running PB 38).

After a File Compare might some sort of thread be left open, locking (at least part of) one of the files in the comparison?

Ran comparison on a number of larger files (>125 MB < 660 MB).
After doing so, after either comparing completely or hitting the 32K difference limit, I ran the same two files through (a Send To shortcut to) Hasher 1.00. In most instances hash computation of one of the two files would at some point stop. If I hit the Pause key in Hasher, a Hasher error comes up "Thread Error: Access is denied (5)". (Doing the same <without extensive testing> using HashMyFiles completed successfully.)

OpenedFilesView did not show the files in question. Did not check using an Sysinternals utilities.

[Jan Rysavy]

Could you please try it without Send To command? It could be faulty shell extension running in our process.

[therube]

There was no shell extension, per se.

I'm not sure if the Hasher .exe version has an option to set one up?

I use the ZIP version & set up a link (.lnk) in \SendTo\ that simply points to C:\DEV\UTILS\Hasher.exe. (So I right-click a file, Send To -> Hasher.)

I can open Hasher first & drag the files into it. I try that this evening.

[Jan Rysavy]

Could you just test Salamander alone, without any other application or Send To functions? The Send To is starting foreign shell extensions in our process...

[therube]

Would drag & drop affect anything (in the way that Send To is), as opposed opening Hasher (or say, Bintext) from outside of a Salamander process?

Why Bintext (& drag&drop) you ask?

Cause I extract an installer, right-clicking the installer, Send To -> UniExtract. (Again simply a link <.lnk> to C:\DEV\UniExtract\UniExtract.exe.)

That extracts the installer contents, creating a few directories & a handful of files within.

Then, I go to drag one of the files into Bintext, but instead of the file opening, I get an error, "Bintext: Unable to open that file". I thought, that's odd, but not unheard of. A file locked by another process is not able to be opened by Bintext. <The change.log of the most recent restore point, C:\System Volume Information\_restore{...}\RP...\change.log, will do that.>

I have no A/V nor any other programs that would be "scanning" files as I open/move them.

PS: I'm actually running an older version 2.04 of Bintext.

So I've now seen these oddities on two different computers, both with PB38. I have not see these oddities with other versions of Salamander. I tried duplicating (on a different, this) computer the Comparator "locking" issue, but was not able to. Intel Core 2 Duo on the earlier post, AMD Sempron on this Bintext'er.


Just happened again, dragging a file into Bintext. But this time I changed to (opened) a different directory, pointed to, then dragged the file into Bintext. Repeated the same a few moments later & it opened as expected.

[Jan Patera]

Would drag & drop affect anything (in the way that Send To is), as opposed opening Hasher (or say,....etc. etc.

Is in this story still File Comparator plugin used? Is its window still opened when you get the error? I'd like to be sure not 2 (or more) issues are mixed here....

[therube]

No, I had closed the Comparator window.

But to me, at this point it is no longer looking to be a Comparator issue, but something more general in Salamander.

Perhaps a change dealing with <what was that background file pane processing change made 2.52>?

[Jan Rysavy]

I must admit I'm totally lost here. We would probably wait for others to confirm this issue...

[therube]

A file locked by another process is not able to be opened by Bintext. <The change.log of the most recent restore point, C:\System Volume Information\_restore{...}\RP...\change.log, will do that.>

Just to point out, that no file within \System Volume Information\ may be "Send To" Bintext (shortcut).
All give the same error, "Bintext: Unable to open that file".
(Though I can "Send To" ... CRC or Hasher or List or Strings or win32pad or ... from within SVI.)

So that is no doing of Salamander.

(Wonders how I never noticed that before?)

But then drag & drop from SVI into a Bintext window does work, except for the (temporary) exception I ran into above.

(I haven't given up on the rest of the thread .)


PS: I never realized that there was a Early Access Program forum, so if any of my posts should be moved there, feel free.

[therube]

Not sure if this is a Salamander issue or not (& I'm running PB 38).

Since I started this, I had upgraded from v1.00 to v1.20 of Hasher.

The other day, I received a "FAILED" error in Hasher when computing hashes on some files.
I reverted to the earlier version of Hasher & still had problems, but instead of a "FAILED" message, I received a "Thread Error: Access is denied (5)" error. It was that message that reminded me of this thread.

I figured that both "FAILED" & "Thread Error: Access is denied (5)" were one in the same, just displayed differently.

At that point, my thought turned to a problem unrelated to Salamander, but with Hasher itself.

Hasher: FAILED (& or) Thread Error: Access is denied (5)

Now the "fix" in this case entails using an entirely differently coded version of the Hasher program.

I haven't run into any problems with this 3alpha version, so at this point, my thought is that this was not a Salamander issue at all, but rather an issue with the Hasher program itself. (Given that, I'm more likely to suspect issues with the other programs where I ran into problems.)