Showing posts with label usb. Show all posts
Showing posts with label usb. Show all posts

Sunday, May 7, 2023

Hard Drive Replacement and USB

Just got a shiny new Western Digital Black 10TB hard drive to replace my somewhat ailing WD 6TB Blue with just over 10 years of solid 24/7 performance. 

Electromechanical hard drives like many electronics in general will likely go the distance if no failures develop in the first few days, weeks, months of use, but over time they do simply begin to wear out. My venerable drive for games and media was beginning to develop subtle issues, like large copy operations interrupted with occasional retries but finally completing, or files that suddenly proved unreadable when trying to access them.

S.M.A.R.T. software on board reported no anomalies other than some higher than normal temperatures (mostly due to a dead case fan I replaced along with the drive) and a couple hundred sector reallocations indicating the drive found some  physically bad sectors and moved what data it could to different ones.

I decided to go the relatively lazy route of taking the old drive out, installing the new one, and planning to transfer the data via USB 3.0. Lazy, mainly because given I'd already installed the new drive and put my rig back together I didn't want to crack the case open again despite the significantly faster direct SATA transfer speeds. That prompted a series of irritating events and I wouldn't be sharing them here otherwise, in case you, dear reader, have recently experienced the following yourself, so there's that.

Upon rebooting my Windows 10 system, all was well for the most part except for the fact that upon opening Disk Management to initialize, allocate partitions, and format the drive, my system suffered its first BSOD of the afternoon, citing a file mrcbt.sys which belongs to backup software I use, Macrium Reflect. Simply restarting afterward seems to have gotten around that issue and my setup booted normally with the newly partitioned and formatted 10TB drive online.

New drive up and running in Disk Management.

Here's where things got irritating. Using a decent USB 3 external hard drive bay by Sabrent I installed my old drive, powered the enclosure up, then plugged it into my USB 3 hub. Immediate BSOD, citing "memory management" issues with no mention of specific files.

I fell back to review my options after a couple more tries leading to the same outcome. I could hook the enclosure up to my wife's PC on our LAN, share it from there, and transfer over the wire. This though would add a lot more time and overhead on top of asking a lot of my senior citizen hard drive in its time of subtle decline. Also, could've hooked it up to a laptop but that would take even longer for transfer of the over 4 TB of data and burden the old drive further.

Ultimately I paid for my laziness and ended up cracking the case open, and as I type the old drive is resting a bit precariously but securely on the floor beside the case providing data to the new drive. Meanwhile I wondered why memory, in this case, was cited as the culprit.

Even after decades of supporting it, Windows to me is largely a black box, even with almost a decade of software and database development on Windows systems. I don't care to delve into the plumbing and avoid doing so whenever possible, but one thing I recalled is the fact that I had been using the old drive to host my system's page file as well as the go-to place for applications and the OS to store temporary files.

From my wife's PC I plugged the drive enclosure in with the old drive on board and tried to delete the TEMP folder. Curiously, Windows wouldn't allow me to do so, presumably because my user account on my PC was owner of that folder. Okay, so I took ownership of the TEMP folder, and then tried to delete all the contents. Curiously, even this didn't quite work. As is typical when trying to delete files from your page file and temp file folder in this case one file refused to be deleted from Windows Explorer.

I opened an administrator authorized Command Prompt, and curiously it not only didn't allow me to delete the file, but kept complaining the file could not be found. What? It's right there, what gives?? I found even after taking ownership, even after being allowed in Explorer to rename the TEMP folder, that one file, a GUID named one resembling daf2743a-311f-4315-9272-be2dca1fa178.tmp, refused to die. Even deleting the folder failed though renaming worked. Weird!

Sabrent USB 3 drive enclosure, for 2.5" and 3.5" drives / SSDs.

I'm used to situations where a Windows PC might BSOD if certain types of USB thumb drives or other peripherals are plugged in and powered on at boot, but this wasn't the case here as the system BSOD'd whether the drive was connected via USB at boot or after the fact. 
That on a foreign system Windows seemingly "respected" the other system's TEMP folder as seems the case here is curious, but perhaps something prompted for security reasons. 

Maybe for Microsoft it was sort of a quick and dirty remediation for a security vulnerability involving bad actors trying to recover data from a stolen operating system drive, where that TEMP folder would typically reside. This though just happened to be a case where instead of using my main SSD with the operating system for it I was using my media drive to house the pagefile and temp files, so perhaps that's why events conspired to not allow that magic to happen via USB.

Simply connecting the old drive directly via SATA to my rig to do the transfer has been operating for minutes now without issue, and given the old drive's TEMP folder still lingers, USB may be the extra ingredient that frustrated my initial, lazy attempts.

Wednesday, January 14, 2015

Logitech k400 Wireless Touch Keyboard Review

As many "smart TV" owners know, "typing" with your TV remote control can be a hassle at best, a pain at worst. Fortunately, there are alternatives when you want to access your TV like you would a PC. 

One is a smartphone app, such as this unofficial one for use with Samsung TVs. Another, especially handy if you don't use a smartphone, is the Logitech k400 keyboard.

Logitech k400 Keyboard

The keyboard has smallish keys and is nearly full-size, but may be a bit irritating for those with fat fingers. The package includes a small transceiver which plugs into a free USB port on your smart TV, as well as a USB range extender smaller than many USB flash drives. 

Samsung, manufacturer of my particular smart TV, "...does not guarantee compatibility with all devices..." (source), but freely list their very own keyboard as wholly compatible, which is convenient for them. However, at least for my Samsung UN46EH5300, this particular keyboard worked out of the box for me.

The keyboard itself uses two AA batteries, and the transceiver runs off the TV's USB power. For your Samsung TV, a button with a right-mouse-button icon will, assuming you're viewing a TV channel, pop up a menu which lets you open Samsung's trademark on-screen menu. From there you can open YouTube and various other online services, and thereafter type URLs in as desired.

So far, my only complaint is that as far as Samsung's built-in web browser goes, you're stuck with ads (which might otherwise be blocked on your PC with the AdBlock Plus browser add-on or other means), and the browser itself for the few sessions I've opened with it so far has frequently crashed.

This does not impugn my impression of the Logitech k400 itself, though; it seems to do exactly what I expect it to do, enable both keyboard and mouse control of my smart TV.


Thursday, October 2, 2008

Running an Ancient dBASE IV Database from Removable Media

I needed to run a particular DOS application from CD, USB, or other removable drive.

This particular application is a database of local community service agencies built in dBASE IV, allowing the user to search among service providers or do keyword searches of available services.

It's nice because the contact and services information for hundreds of agencies could fit neatly on a 3.5" diskette, but not so nice because it's a DOS-based app. The app for my purposes needed to be able to run from CD or USB flash drive, the goal being to be able allow the user
to easily assess and play around with its features, and have a functional replica to use in refactoring its functionality into a more up-to-date database and user interface platform. That, and the fact that the computer to use for testing has no 3.5" diskette drive installed.

In the interests of time, I decided to create a batch file to execute the app. One twist, however, is that the app must run from the C: drive, because it's hard-coded to reference the primary hard drive in a PC.

I decided to create a batch file which would perform the following steps:
  1. Create a new folder on the temporary file area of the C: drive.
  2. Copy all files from the removable media to the new folder.
  3. Execute the DOS app.
  4. Upon exit, delete the folder from the C: drive.
The app would be running from within a DOS command prompt under Windows XP. One quirk, as CPU clock speeds have increased over the years, dBASE IV has issues which prevent it from executing normally on its own. Specifically, dBASE attempts to perform some temporary file housekeeping based on the system clock, and on any system faster than oh, 133 MHz or so (at least in my testing), dBASE would fail to launch.

Thankfully the utility IDXFIX proved to be the magic bullet for this little problem, my thanks to Gary White, creator of this, wherever he may be. This utility just needs to be run prior to dBASE to set up shop for it and presumably intercept and handle requests dBASE makes when trying to interface with the clock.

Here's the batch file, an explanation follows.

md %temp%\myProg
xcopy *.* %temp%\
myProg /s /e /v /y
cd %temp%\
idxfix /I
dbase.exe %temp%\
idxfix /U
cd %temp%\
del %temp%\
myProg\ /s /q
rd %temp%\
myProg\ /s /q

Now on to the explanation.



  • Just tells the command prompt to not echo commands, and to clear the screen. In a way redundant, but this is habit from when I had to write batch files more frequently, and it does make testing a little cleaner.

md %temp%\myProg
  • This simply looks at the %temp% environment variable, which in Windows XP references the folder on the Windows install drive where temporary files are stored. By default this references a folder under C:\Documents and Settings\<userName>\Local Settings\Temp. I just changed this on the target system to a folder I created named C:\TEMP, for simplicity and to avoid any potential issues with long file names with this old DOS application.

xcopy *.* %temp%\myProg /s /e /v /y
  • This uses the command-line xcopy program to copy the entire file and folder structure from the removable media to the temporary file area on the C: drive. The parameters tell it to copy subdirectories, include empty subdirectories, verify the results, and automatically overwrite any existing files.

cd %temp%\myProg\dbase
  • Change directory to the dbase subfolder copied from the removable media. This is the folder where the dBASE executable, dbase.exe, lives.

idxfix /I
  • This loads the IDXFIX utility into memory as a TSR, short for Terminate and Stay Resident. The utility's execution doesn't stop any further actions in this particular instance of the command prompt, but still hangs out in memory to serve whatever purpose, in this case ensuring dBASE can execute properly.

dbase.exe %temp%\myProg\db\myDB.prg
  • This executes the dbase.exe executable and tells it to load the file myDB.prg, which represents the database application.

idxfix /U
  • When the batch file gets to this point, the user has quit dBASE. Thus, we unload the IDXFIX utility from memory.

cd %temp%\

  • Ensure we've changed to the temporary folder, so that our focus is NOT inside the folder or any subfolders of our copy of the database application. If this were the case, the next steps to remove the application files and folders from the target computer's hard drive would fail.

del %temp%\
myProg\ /s /q
  • Deletes files contained in the database application folder. The /s parameter ensures all files in all subfolders are deleted, while /q tells the delete operation to not ask for confirmation. We know what we're doing!

rd %temp%\
myProg\ /s /q
  • Removes the folder and all subfolders. Another option would've been to utilize the DELTREE executable, but DEL serves the purpose just fine as it's integrated into the XP command prompt, whereas DELTREE is a separate executable we'd need to store on the removable media.

In summary, this batch file has enabled us to run this ancient DOS-based database application comfortably from within a Windows XP command prompt. It sets up shop for itself on the C: drive, executes and enables the user to use the full functionality of the database, then wipes traces of itself from the hard drive upon exit.

This is a task which in a way seems rather pointless. However, these steps have enabled us to take an old DOS database application which previously could only run from a 3.5" diskette, and essentially make it portable so that it can now be run from any removable media.

If during some natural disaster or other crisis, someone needed this particular database to view on a laptop with no wifi handy, these steps would enable this accessibility.