Etcher: Etcher.exe creates/runs batch script every 2 seconds indefinitely, at idle

Created on 5 Jul 2017  Â·  6Comments  Â·  Source: balena-io/etcher

  • Version 1.0.0
  • Windows 10 64-bit
  • Burning images not necessary to recreate error
  • Nothing in DevTools that helps

My hard drive was filling up, so I did some analysis and found an obscene number of temp files in %UserProfile%\AppData\Local\Temp. They're all the same exact file, but with a different random name, according to the convention:
tmp-<pid><randomchar x12>.bat

Every 2 seconds, I see this Etcher process create a cmd process to run this batch script. It is the second of three subthreads of Etcher.exe, run with --renderer.

image

I haven't looked too much into what the script does, but I found a copy of it uploaded to both Pastebin and VirusTotal.

Recreating the issue is as simple as just executing Etcher.exe and letting it run.

It has created over 1000 files in the time it took me to write this.
image

image

It should be noted that this doesn't noticeably impact the performance of Etcher - I've created a few images in the last day or two. The only reason this came to my attention is because it was filling up my disk. At this rate, it consumes 354MB of disk daily. That's less of a concern than the 43,200 files created daily. At about 100,000 files, Windows Explorer starts to choke when you try to browse a directory.

Again, this is a great piece of software - imaging stuff is so much easier. Just a bit alarmed to see this churning out more than just images ;)

all bug

Most helpful comment

Tested the Win64 nightly posted over here - runs great! Noticeably faster also, both startup and doing things within it. Thanks everyone!

All 6 comments

Hey @Sawaba, thank you for bringing this up! This is a beautiful bug report :)

The culprit here is resin-io-modules/drivelist, which Etcher uses to scan for storage devices. It does look a lot like there's something fishy going on due to the location and name of the files; but the only thing that happens is that drivelist creates a script to get the drives, as that was the easiest way to get a list of disks with sizes etc. at the time, without using native APIs.

We were aware of this looking mildly strange, and being problematic at times, as anti-virus programs also sometimes picked this up (so it being on Pastebin & VirusTotal isn't surprising). Drivelist not cleaning up after itself is something we haven't noticed so far though (as none of us actually have been running Etcher for that long at a time I think).

I have created an issue for this on drivelist (https://github.com/resin-io-modules/drivelist/issues/190) to also track this there.

We have implemented this in C++ for Windows recently, and native bindings for Linux & Mac OS will soon follow, and then that'll land in Etcher 1.1.0 – so all this should go away then.

Excellent, thanks for the response!

I don't understand the challenges and constraints involved so take my statements with a grain of salt. My thoughts are that an app like Etcher should ideally check storage devices on startup, and again only if a change in storage devices occurs. I'm guessing that will be easier in a native, non JS-based version :)

The Windows version (of drivelist) is based on C++ now, but no OS API allows to "listen" for events, so we have to manually poll anyway.

I suspect (but this is just a wild uninformed guess!) that listening for device-change events _might_ be possible using udev on Linux, but given the cross-platform nature of Etcher it's obviously easier to just poll for changes.

Tested the Win64 nightly posted over here - runs great! Noticeably faster also, both startup and doing things within it. Thanks everyone!

Was this page helpful?
0 / 5 - 0 ratings