Re: IMG-nnnnnnnn.tmp files
"Franc Zabkar" <fzabkar@iinternode.on.net> wrote in message
news:b8h7d3tc4lvg19bgkt8pvd2kc657o0fmh3@4ax.com
| On Mon, 27 Aug 2007 15:45:38 -0400, "PCR" <pcrrcp@netzero.net> put
| finger to keyboard and composed:
|
|>"Franc Zabkar" <fzabkar@iinternode.on.net> wrote in message
|>news:grp4d35qfujanuoooai7fh2anc5vkcqqt1@4ax.com
|>| On Sat, 25 Aug 2007 16:17:30 -0700, "Gary S. Terhune" <none> put
|>| finger to keyboard and composed:
|>|
|>|>Let us know when you figure it out, Franc, <g&d>.
|>|
|>| The culprit appears to be Explorer.
|>|
|>| Here are two Filemon screenshots, the first from the beginning of
|>| the log, the second from the end:
|>|
|>|
http://www.users.on.net/~fzabkar/IMG-00000000_start.gif
|>|
http://www.users.on.net/~fzabkar/IMG-00000000_end.gif
|>|
|>| The IMG-00000000.tmp file was created while I was using Explorer to
|>| backup a large amount of data from drive C: to drive D:. Subsequent
|>| backups did not consistently produce the same outcome.
|>
|>I'm thinking... these .tmp files might be something Explorer normally
|>would delete after use. Explorer creates them on E:\TEMP, where you
|>have moved TEMP. There may be a circumstance in which Explorer
|>forgets TEMP has been moved there, & tries to delete them from
|>"C:\Windows\Temp". (OTOH, it might actually remember where TEMP is, &
|>simply forget to do the delete.) Anyhow... perhaps, REM those lines
|>in Autoexec.bat, & see what happens!
|
| OK, I was going to try this suggestion at the next reboot but I think
| I have solved the problem. See my reply to Gary.
I saw. It does seem rather certain ReaConverter is involved in some way.
I don't know the app, but, if it is normal for it to create these files
in normal use-- I GUESS it is implicated in the appearance of the
abnormal ones! Yea, uninstall & monitor, just as you said. That's
probably it, as far as the files are concerned. If you miss
ReaConverter, try reinstalling afterward-- just to see whether it will
work right next time.
Looks like it was confusion in the context menus, except I can't think
how "using regedit to export my registry to a file" involves a context
menu at all.
My other thought is that... even if having moved TEMP is involved... I
can't figure how/why ReaConverter would be wanting to create these files
(for it to fail to delete)... when NOT specifically requested to do a
conversion in the first place.
|>As Bear wants to know... how precisely do you do this backup? Just a
|>copy/paste from Explorer, ...
|
| Yes, and I do this within the same Explorer window, if that makes any
| difference.
Hmm. It could make a difference as to which Explorer window would
freeze, maybe-- or I vaguely recall Chauvin may have said. But I have
always used the same window. Yea, when you do a massive
move/copy/especially delete of a massive number of files or of folders
full of folders & files-- yea, there is a slugishness afterwards. Wait
for it to complete, a reboot afterwards will clear it all up. Other apps
will continue to work well even w/o the reboot-- but things like the
START menu are Explorer-related & will be sluggish! As Chauvin said, it
is a cumulative thing. SO, until the reboot, your very next file delete
could cause the problem-- even a zero byte file!
I doubt this relates to the ReaConverter problem, unless it only happens
under such conditions. BUT-- since you never specifically activated
ReaConverter, it's odd it should be creating those files, anyhow. Still,
it might take a reboot to have Explorer update its display well enough
to fill in zeros with proper file sizes-- which is one of the symptoms
you reported earlier.
If this all happens a lot-- use a 3rd party tool to do the massive copy
or delete, or do it in DOS, which does not suffer the problem.
|> ... or something like MSBackup? Are there any
|>extremely large files involved?
|
| Not really. I'd say the largest may be around 20MB, but most are much
| smaller.
OK. It isn't the size of files, but the number of them that are involved
in the sluggishness problem.
| One thing I notice is that after these large file transfers, Explorer
| slows to a crawl. For example, it may take a whole minute to refresh
| the screen. I seem to recall several discussions about directories
| with > 2000 entries causing slowdowns, but I don't know whether this
| is what I'm seeing. My largest subdirectory (browser cache) has about
| 900 files.
That probably isn't enough to do it-- except it is a cumulative problem.
Every file you do adds to it, until a reboot is done. But it's usually a
big number!
| Sometimes when this happens, Resource Meter's display drops into the
| red, or very close to it.
Yep. I actually would get the Low Resources requestor to shut some
apps-- BUT sometimes that will be hidden behind a frozen Explorer
screen! And it's only a reboot that is the cure! Actually, the other
apps work well!
| As I said above, I have solved my problem, but this Explorer slowdown
| may be an unrelated issue. I'm now monitoring it.
Keep us informed.
|>Is it normal, Windows files, or
|>downloads or creations of your own? Any with "IMG" in their name?
|
| The files consist mostly of downloads and personal documents, but none
| with IMG in the name. Anyway, it turns out that ReaConverter was
| interfering with Explorer in some way (probably via the context menu),
| but I'm damned if I know how or why.
|
|>I guess I can devise a test of my own, if I knew these were normal
|>files & how many you try to copy at once. I guess I can move my own
|>TEMP to my own E:, or use...
|>
http://www.snapfiles.com/get/restoration.html Restoration
|>...to see what may have been created & deleted from C:\Windows\TEMP
|>after such an operation.
|>
|>Here is how to see whether you have a BHO as Terhune may suspect...
|>
|>
http://www.definitivesolutions.com/ BHODemon
|>This one was free last I knew. It renames the BHO executable & can
|>"undo" that.
|>
|>
http://www.pcmag.com/ 's "BHOCop" removes a BHO's Registry entries &
|>can "undo" that. It found a Browser Helper Object called Wavehelper
|>Class, created by "Wavetop", that was building a monstrosity of an
|>error log called "Logit.txt" in here. "START button, Find, F/F,
|>Logit.txt"-- see one?
|>
|>| One strange observation is that, even with View -> Refresh, Explorer
|>| showed the file size as zero until after a reboot, at which time it
|>| became 497KB.
|>|
|>| BTW, Filemon's Save and Save As functions do not appear to work.
|>|
|>|>Gary S. Terhune
|>|>MS-MVP Shell/User
|>|>
www.grystmill.com
|>|>
|>|>"Franc Zabkar" <fzabkar@iinternode.on.net> wrote in message
|>|>news:vva1d3tvr9bvmk0qb0m056jgbs1tcg88br@4ax.com...
|>|>> My TEMP directory contains files of the type IMG-nnnnnnnn.tmp.
|>|>>
|>|>> E:\Temp\IMG-22EF1586.tmp
|>|>> E:\Temp\IMG-04044202.tmp
|>|>> E:\Temp\IMG-14B5B6BB.tmp
|>|>> E:\Temp\IMG-19EE2C4D.tmp
|>|>> E:\Temp\IMG-00000000.tmp
|>|>> E:\Temp\IMG-28CAE025.tmp
|>|>> E:\Temp\IMG-2FA581AC.tmp
|>|>> E:\Temp\IMG-55F8C5A0.tmp
|>|>> E:\Temp\IMG-6E36D60E.tmp
|>|>>
|>|>> Their lengths are either 508,196 or 106,568 bytes. The larger
|>|>> files appear to consist of 337 blocks containing 1506 C0h bytes
|>|>> plus two zero bytes. The last block sometimes contains what looks
|>|>> like a file remnant, either text or binary. The smaller files
|>|>> consist of 173 blocks containing 615 C0h bytes plus one zero byte.
|>|>>
|>|>> If I delete these files, they will reappear the following day,
|>|>> some with the same name.
|
| - Franc Zabkar
| --
| Please remove one 'i' from my address when replying by email.
--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
Should things get worse after this,
PCR
pcrrcp@netzero.net
artition?
