Data Nightmare: Reconciling Two Hard Drives

I was using Windows 7.  I had an old hard drive with files on it.  I wanted to see whether its files also existed on a newer drive.  My concern was that some of the old files might not have made it in good condition to the new drive.  This post describes the somewhat haphazard steps I took in this project. 

This is an incomplete account.  Ultimately, I was able to proceed only partway, with steps like those described here.  These steps got rid of half of the old files; I was able to see, fairly quickly, that at least half of them were duplicative or superseded.  When I closed this post, I was still not sure how I would be able to decide what to make of the other half of those files, other than through a long, manual file comparison process.
One first step, I thought, might have been to keep a complete directory listing from the old drive.  There were some scenarios where that might have been useful, and it was easy to make.  There were freeware utilities that would do it.  I would have just used the DIR command.  The commands I would have used would have been something like this:

F:
cd \
DIR *.* /s > D:\F-LIST.TXT

where F was the old drive, "cd \" started me in the root of F, and DIR put the names of all files, including those in subdirectories, in a file called D:\F-LIST.TXT.

Anyway, I decided to reduce the size of the problem by eliminating files on F that seemed very likely to have made a successful transition to the new drive (drive E).  Ideally, I would have made a backup copy of F before doing this, just in case some of my steps erred.

To delete those files that had successfully transitioned from F to E, I used DoubleKiller, though there were other duplicate remover programs that would have done the job too.  The criteria I used at this point were to check both the file sizes and the CRC32 checksums.  (Not all duplicate remover programs had these options, but some others did have something similar.)  The concept here was that a file's size could be the same and yet its contents could have changed, so it would pass a size-only test; and it was conceivable that two very different files could have the same CRC32 checksums; but it was virtually certain that if both the size and the CRC32 checksum were identical, they were in fact identical files, in which case one could safely be deleted.  I searched drive E for duplicates within itself, and resolved all of those.  Then I did likewise on F.  With that done, I could now check on both E and F.  DoubleKiller would display the duplicates in pairs, with E coming first and F coming second, so I could then do a bulk check-and-delete process (after some additional eyeballing) to remove the duplicates from F that had almost certainly made it to E successfully.

While doing all that, I noticed that a lot of files had changed format.  They had been .doc or .txt files, but I had converted them to .pdf.  This process would result in a file that had a different size, checksum, and filename.  But experience with the newer files, supplemented now by some random checking of these .pdfs, convinced me that most if not all with the new (*.pdf) filenames did reflect the same content.  So I could also delete the old .doc and .txt (and other extension) files on the old F drive whose content appeared to have made the transition to .pdf on the new E drive.  Space and time permitting, I could have played with that question some more and probably improved the accuracy of this comparison.

I could delete the old files (with .txt, .doc, etc. extensions) in favor of the new PDFs, that is, if I could figure out which ones had been so converted.  Consider these two filenames:

Letter to John Doe Containing Information.doc
Letter to John Doe Containing Information.pdf

If they were in the same folder, I could just sort them by file type in Windows Explorer, select the ones of the old type (.doc, in this example), then sort by name, and eyeball to make sure I had alternating selected and unselected files.  The problem in my case was that some of these, after being converted to .pdf, had also been moved to other folders.

To address that, I knew of two solutions.  One was the easy solution.  This apparently involved using Beyond Compare, or something like it, in its Professional version, and figuring out how to ignore filetypes so that I would have a straight-across comparison on two columns.  I had the Standard version, so I didn't have that option and, at this point, didn't even know that option existed.  What I was seeing in my Standard version of Beyond Compare was a more alternating layout that, when other files were added to the mix, could be hard to decipher, especially when dealing with large numbers of files that I did not care to scrutinize one-by-one.

As I say, that was the easy solution, so of course the solution I took was, instead, to produce a list of files on drive F, using the DIR command (above), and compare it against a list of files on drive E.  Since there were more than 65,000 files altogether, I could not simply copy these resulting E-LIST.TXT and F-LIST.TXT files into Microsoft Excel; its maximum was about 65,000 rows.  I discovered that OpenOffice.org (OOo) Calc had a similar limit, but a variant version of OOo Calc had a maximum of one million rows.  This version, called Go-OO, was delighted to accept my long E-LIST.TXT and F-LIST.TXT file listings, and it went right to work on them, crashing every couple of minutes.  After spending hours paring down the files to a somewhat smaller size, and converting formulas to simple text and numeric data (using Edit-Copy, Edit-Paste Special) as soon as I didn't need the formulas anymore, I was able to reduce the crashing.  By using text analysis functions (especially FIND and MID) within Go-OO, I was able to extract the filenames without extensions.  Now the problem was just getting Go-OO to copy and paste the lookup formula that I was using to search for the F filenames without extensions against the derived list of E filenames without extensions.  Go-OO was unwilling to copy and paste those formulas en masse; the very idea would cause it to freeze in fear.  Since I did not want to paste the formula manually down tens of thousands of rows, a few at a time, I wound up using AutoHotKey to automate the copying of those formulas.  AutoHotKey was useful if somewhat childlike.  I found, for instance, that if I absentmindedly switched the focus on that computer away from the copying process underway in Go-OO, AutoHotKey would blithely continue copying and pasting things into whatever random windows happened to be opened.  Fortunately, there were no delete commands in my AutoHotKey script, else it would have been an unpleasant morning.  Sometimes AutoHotKey would also decide to just start working away in some other part of the spreadsheet.  Should anyone care, the AutoHotKey macro that I prepared for this project went like this:

!x::

; Copies a cell in OOo Calc to the next one down
Send ^c{down}{Enter}{down}{up}

At this point, I wrote up these additional notes, which did not actually turn out to describe what happened next, but which may be useful for someone else who shares my indulgence in fantasy.  First, I said, "When the lookups were done and I was finally working with fewer than 65,000 files, I saved in an Excel-compatible format and resumed work there."  I also wrote, "Eventually, I noticed that some files that had previously been .jpgs were probably combined into .pdfs as well.  Since .jpg format did not accommodate multipage documents, what we had there was a bunch of files named file01.jpg, file02.jpg, file03.jpg, and so forth, and the resulting file.pdf.  So here I had to modify the spreadsheet formula somewhat to seek out those filenames ending in two or three digits, and search for equivalents along those lines."

Those additional notes did not turn into anything real because what happened instead was that Go-OO -- whether of its own volition, or as persuaded by AutoHotKey, I cannot say -- decided not to reopen the file anymore, nor any of its last several versions comprising hours of work on the spreadsheet.  After trying various angles on two different machines, I gave up and waited for news from the Beyond Compare people on what it would cost to upgrade from Standard to Pro version, so maybe they would provide a workable solution to this project.  It turned out that a previous version of Beyond Compare had a way of comparing that might be useful, so I looked into that but, unfortunately, I would have needed some of the features of the latest version to make it work.  Another Beyond Compare approach involved their Alignment Overrides option.  They had a way to experiment with this feature, which was in the Pro version.  This did not really help me much.

I wound up using Beyond Compare 3, using folder-by-folder comparisons and also comparisons regardless of folder.  I simply deleted, from the old drive, the files that were matched on the new one.  This left a bunch of empty folders.  I had always gotten rid of those using a batch file in a sequence of several steps, but I had never memorized exactly what those steps were, and what I was finding now wasn't working right.  I heard that Glary Utilities had a tool for this purpose, so I installed that freeware and went into its Modules tab > Files & Folders > Empty Folders Finder.  It found a boatload of them. Once that was out of the way, I ran the DOS command "DIR *.* /s > D:\DIRLIST.TXT."  This created DIRLIST.TXT, a list of the files left on the drive.  I imported that list into Excel -- it was now short enough to fit within the 65,000-record limit -- and sliced and diced it.  I started by using commands like MID and FIND to extract the file extensions.  Example:  =MID(F1,1,LEN(F1)-LEN(K1)), with F1 containing the imported filename and K1 containing the extension (e.g., .html), would give me the filename without extension.  (To get the extension, I did several columns of =FIND(".",F1,G1+1), where G1 contained the rightmost dot yet discovered in the filename, sorting and identifying and then excluding from further sorts.  Then I used ="DIR /S "&CHAR(34)&I2&"*.*"&CHAR(34)&" >> D:\FOUND_IT.TXT" to create a cell containing a DOS command that would look like this:  DIR /S "Letter to Joe*.*" >> D:\FOUND_IT.TXT.  This command would search for that filename and export its results to FOUND_IT.TXT.  Excel generated similar commands for each of the files I was looking for.  I copied and pasted the lot of them into a text file called Finder.bat.  At the start of Finder.bat, I added two lines:

D:
CD \

to make sure that the search would occur on the proper drive and would begin from its root.  I ran this overnight, and awoke to find that FOUND_IT.TXT had vanished.  No idea why.  So I ran it again, and this time simulataneously ran another batch file:

:: WAITER.BAT
:: Copies FOUND_IT.TXT to another folder
@echo off

:REPEET
copy FOUND_IT.TXT D:\Current
TIMEOUT /T 30 /NOBREAK
goto REPEET

Ultimately, this gave me a complete FOUND_IT.TXT, with lots of hits and misses.  I opened it in Word.  It was a 9,193-page document.  I did a bunch of search and replaces to get rid of useless lines, using search and replace terms like ^p (for line breaks) and ^t (for tabs).  At this point, I did not continue with the process of examining drive contents and logging my steps, deciding instead to defer this process until the next point when I would want to devote some time to this enterprise.

A Two-Computers-Per-User Desktop Arrangement

I was spending a lot of time at my desk, doing word processing and other typical desktop work.  For this purpose I was using a customized Windows 7 installation on two networked computers for maximum productivity.  This post describes that setup.

I had previously thought that, ideally, I would have four computers:  one laptop; one test machine to hook up the occasional hard drive or other component for wiping, testing, etc.; and two desktop machines running side-by-side.  Since then, however, I had switched from Ubuntu back to Windows and had found this to be a good move.  So now I was doing very little testing and tinkering with hardware.  Therefore, I dismantled and sold the parts from the fourth computer.

With almost all of my work happening on just two computers, and with a stable Win7 installation on each, the focus now was on getting the most out of them.  I was using two desktop computers instead of one because there were still many occasions when a computer would experience downtime.  I would be doing drive maintenance or imaging, or would still have to reboot Windows now and then to clear its head or to complete a program installation or upgrade, or Win7 would be running just fine but there would be some scanning or something else going on that would tend to monopolize the machine for practical purposes.  I was not yet very impressed with multiple desktop software and was considering a return to VMware or some other virtual machine software, perhaps in a virtual appliance, though I wasn't sure I wanted to get back into the performance issues that had prompted me to try to use a native and/or bootable virtual hard disk or RAID array to improve the really bad performance I had started getting in VMware.  So the second computer was also useful as a simple way of having a pretty solid alternate desktop.  I could start up a project or leave a set of folders open there and just visit it occasionally, when the primary computer was doing its own maintenance or was otherwise unavailable for a while.

The starting point for this two-computer arrangement was to set up two machines that were almost identical in terms of hardware and software.  In previous years, I had thought it was best to have dissimilar machines, so as to maximize resources.  One machine or the other would have the right hardware or software to deal with almost any kind of system problem.  That belief was probably justified for some purposes.  Now, however, I was less patient with that, and it also seemed less necessary.  A lot of the old problems had gone away.  Meanwhile, it was much easier to learn how to maintain and troubleshoot just one set of problems, rather than have to learn the whys and wherefores of divergent sets of hardware and software.  For purposes of getting my work done, Windows 7 was a significant improvement over operating systems I had used previously, including Windows XP and Ubuntu 10.10, in terms of networking and other capabilities.

The customized Win7 installation (see link above) was not as easy as a canned, plain-vanilla installation, but once I had it set up, it had some advantages.  One important step was to make my work files available on both computers.  My first attempt in this regard was to use a Synology network-attached storage (NAS) unit as a simplified file server, but that hadn't worked so well for me.  In the second attempt, I used my home network (basically, just a router and cables to the two computers, though possibly a crossover cable would have sufficed even without the router).  After some contemplation, I went with GoodSync to keep the two computers directly synchronized with one another.  This was an important development.  When combined with appropriate program settings (e.g., setting Microsoft Word to AutoRecover files every minute), it meant that, if the computer I was working on suddenly crashed or otherwise became unavailable, I could usually switch over to the other machine and pick up right where I left off.

I used GoodSync to synchronize my data partition (drive D), not the program partition (drive C).  I also used it to synchronize parts of the INSTALL partition, including particularly the funky but advantageous shared Start menu.  GoodSync did not need to be running on both computers, so I installed it on computer A.  As the installation evolved, I found that computer A was handling most of my computer maintenance and other functions, while I did more of my moment-by-moment productivity stuff on computer B.  In particular, computer A was becoming my backup hub.  I would save a file on computer B; GoodSync would copy it to computer A; and then my backup software would copy it to other drives.  After a variety of unpleasant backup surprises, I had evolved to two distinct backup systems running on computer A.  In the first backup system, I was using Robocopy, as part of my customized installation (above), to make frequent, incremental backups to a separate partition on computer A.  This was one of the few regards in which computer A differed from computer B in terms of hardware:  it had three hard drives rather than two, so as to speed this internal copying (since it was faster to copy from one hard drive to another, rather than between partitions on the same drive) and make it safer (since a failure of one drive would usually not affect the other).  In the second backup system, I was using Beyond Compare to do daily manual backups to an external drive that I could carry or store offsite as needed.  These were manual in the sense that I had to click things to make them happen, and could therefore examine or at least spot-check what was going to be changed, if I wanted to.

Again, I could still use either computer to do my work, since they both had the same synchronized files and nearly identical software installations.  Nonetheless, as the functions of the two computers diverged, I found that I was not really utilizing both monitors most of the time.  On computer B, I tended to be opening PDFs, Word docs, Excel spreadsheets, Windows Explorer sessions, and webpages, among which I would copy text, links, and other materials.  I could open some of that stuff on computer A instead, but it was cumbersome to have this happening on two different computers, and for the most part it actually was not happening on computer A.  That computer, and its associated monitor, were mostly just sitting there, working up a file comparison in Beyond Compare or otherwise doing things that did not really need to be watched constantly.

What I really wanted was to make monitor A available for computer A, when I wanted to see what was happening on computer A, but to have monitor A also available for computer B, when I was doing my ongoing work on computer B.  This called for a keyboard-video-mouse (KVM) switch.  The PS/2 type of KVM was better for purposes of providing keyboard and mouse input during BIOS setup and in programs that would boot from a CD (e.g., Acronis Drive Image) and would therefore be at least partly unresponsive to a USB mouse and/or keyboard.  Unfortunately, I did not realize that the type of motherboard I had installed in both computers did not have two PS/2 ports, so I had to use a USB KVM.  It also seemed that I might have to spring for a more expensive DVI-compatible KVM, since I'd gotten some poor video performance when I had connected the monitor to the computer using the older D-Sub rather than the newer DVI kind of cable.  In recent months I had been using the KVM only for the keyboard, while leaving each monitor dedicated to one computer and experimenting with having a separate mouse for each computer, so that I could click without having to transfer keyboard (and, optionally, monitor) focus between computers.  It had lately occurred to me, though, that the D-Sub video quality problems might just be due to the quality of the video circuits on the motherboard.  So at this point I was planning to get a dedicated video card for each computer and see whether its D-Sub connection would work acceptably, in which case I could use the USB/D-Sub KVM for the keyboard and for D-Sub video with monitor A.  In other words, monitor B would continue to be dedicated to computer B, but monitor A would run to the KVM and could thus toggle between computers A and B.

This left the problem that, as I had discovered, when I was not seeing events on computer A, I tended not to use that computer.  That was not terrible -- it would still be there as a running backup, ready to jump into service when I needed it, unless it hibernated itself in the meantime -- but experience suggested that, if I could not just glance to see what was happening on computer A, I would tend not to toggle over there on the KVM and take a peek.  I thought of two solutions to this.  One was to set up a reminder that would prompt me, every hour or two, to interrupt what I was doing on computer B, toggle the KVM, and look at events on computer A as displayed on monitor A.  I suspected I might tend to disregard that kind of reminder, but I decided to give it a try.  An alternative was to get a small, dedicated monitor that would just always be displaying events on computer A, though I realized its tiny resolution would not very well display all the stuff that would tend to appear on my widescreen monitor A.  It looked like I could get a monochrome 10-inch Miracle Business MT209A CRT on eBay for $25 including shipping, but I didn't want the clutter or the extra power consumption.  What seemed like a more practical option was rather to go with a full-sized monitor dedicated to computer A.

That's where this matter rested for the time being.

Long-Term Backup Verification: Beyond Compare, in Windows and Ubuntu

Some time back, I had looked into software that would verify that I was not losing data without realizing it. Data could disappear, as I have discovered, when files become corrupted but continue to look the same (until you try to open them). Data could also disappear if files quietly vanish through unnoticed mistakes (e.g., hitting Delete when an archival folder is highlighted). I had a backup system, in other words, but I lacked a way of checking whether anything might be falling through the cracks. The programs I had examined in my previous investigation had not turned out to be quite what I was looking for, so I still had this need.

Then I became aware of Beyond Compare from Scooter Software. BC had gotten a lot of very positive reviews from programmers and other users here and there. It came with a 30-day free trial offer, after which it would cost me $30. Amid praises that sometimes seemed to come from BC's own friends and/or employees, there were also references to Araxis Merge, which some considered much superior. After expiration of the trial period, it was available for $169/259 (standard/professional), but there was supposedly an academic discount of about 70%. Araxis Merge didn't offer a Linux version. There were also a number of other file and folder comparison tools, some of which were free but few of which offered CRC checksum calculation, which I wanted. I decided to start with BC and see how that went.

First Try: Ubuntu Installation

There were versions of BC for Windows and for Linux. In the spirit of my gradual, long-term effort to move away from Windows, I decided to start by trying the Linux version of the program. I was running 64-bit Ubuntu 9.04 (Jaunty Jackalope). Beyond Compare was a 32-bit program.

The 32-bit version may have been very easy to install. But it seemed I would have to make some adjustments in order to run this program on my 64-bit system. I found two different sets of advice on how to make those adjustments. One was for running BC on 32-bit Kubuntu 8.04. I figured it would probably work, if I wanted to try it. But the other was for Ubuntu 9.04, so I decided to try that one.

Following the latter set of instructions, I downloaded the .tar.gz version of BC. Ordinarily, it seems, it would have been necessary to download ia32-libs and libqt3-mt; but in my way of installing Ubuntu, Synaptic showed that these packages were already installed. I unzipped (technically, I guess, I should say untarred) the file by using the "tar -zxf [filename]" format instead of the "tar -vxf [filename]" format that I had previously decided I should use. (I was definitely still in a learning mode for purposes of Ubuntu commands.) Just out of curiosity, I deleted the resulting folder, went into a WinXP VM, right-clicked on the .tar.gz file, and told 7Zip (one of my Windows XP utilities, with a right-click context menu option) to unzip it. It did. Once again, I had that folder containing a file called bcompare-3.1.4.10554.tar. So if, like me, you weren't smart enough to just right-click on the tar.gz file and select Open with Archive Manager > Extract, you could do it this other way. Actually, in this case, the Windows approach may have been superior, because when I did belatedly try the Archive Manager approach, I got "An error occurred while extracting files." So I went back and did it with Windows again after all. This gave me a much larger .tar archive. I used 7zip in WinXP again on this .tar file. Now I had a regular folder called bcompare-3.1.4.10554.

I decided to continue trying the GUI approach. In Ubuntu's File Browser, I went into the unzipped folder and double-clicked on install.sh. I got a dialog asking, "Do you want to run 'install.sh', or display its contents?" I chose Run. Nothing seemed to happen. I went back to Terminal, navigated into that folder, and (reverting to the instructions) typed "sudo ./install sh". Now it seemed to install. At the end of its various messages, it said, "Please place the following in your .bashrc or .cshrc (etc.): export PATH=/home/ray/bin:$PATH," where "ray" was my username. It also said, "Executable is /home/ray/bin/bcompare." It was apparently telling me that I had to add /home/ray/bin to my computer's path, so that the program would know where to look when I typed "bcompare" (or whatever) to start the program.

I tried just typing "bcompare" right where I was in Terminal, but no joy. So I navigated over to where it said it had installed itself: "cd /home/ray/bin." Sure enough, there was a file called "bcompare." But when I typed "bcompare" there, I just got "command not found." Double-clicking on bcompare didn't do anything either. The installation instructions cited above said nothing about this. Was I supposed to make it executable? I typed "chmod +x bcompare" and then typed "bcompare" again, but this still just gave me "command not found."

It seemed I would have to figure out how to add something to my path, though I didn't understand what good that would be, if the damn thing wasn't executable. I found instructions that seemed to work, or at least they got me to an open .bashrc file. I didn't find any path lines in that file to use as a model, so I gathered that I was just supposed to type exactly what they said. I added it at the end of the .bashrc file as follows:

# add Beyond Compare to path [this is a non-executing comment]

export PATH=/home/ray/bin:$PATH

I saved and closed .bashrc. I opened a new Terminal session and typed "bcompare" at the $ prompt. It said "bcompare: command not found." I navigated to /home/ray/bin and tried again. Same result. I decided to back up and try the approach from that other webpage, the one that was supposed to work in Kubuntu 8.04 with the .deb download. Given ia32-libs and libqt3-mt (above), it now appeared that I had assumed that the installation of these libraries meant that the files I needed were installed in the right places -- that, in other words, Synaptic had already taken care of putting those lib files in their proper places. But now it seemed that I should have copied over program files from one folder to another. Putting this Kubuntu approach on hold, I reverted to the instructions from the approach I had already worked through. Specifically, the first command I apparently needed to enter was:

dpkg-deb --extract libqt3-mt_3.3.8-b-5ubuntu1_i386.deb libqt3-mt

changing the specific libqt3-mt file name as needed. But at this point, not knowing what particular file that might be, I said to hell with it and downloaded the Windows version instead. I then looked for a way to uninstall this version of Beyond Compare from my Ubuntu installation; but since I had not used Synaptic to install it, I did not seem to be finding uninstallation instructions that applied. So it's still installed.

Second Try: Windows XP Installation

I downloaded and ran the WinXP installer. Interestingly, they had an option to create a "portable install," which could apparently be put on a removable USB drive or wherever, without making any changes to the registry. Presumably it would still fail to work after the 30-day trial period unless I bought a license. But if I was going to keep the program, this would definitely be a useful form for it. So I went with that approach. (One special advantage of this approach, for my purposes, was that I could put it on a drive other than drive C, within my computer, and could therefore make it available to all of my virtual machines under VMware Workstation, without having to reinstall it on each VM.)

The program seemed good. I was impressed with the comparisons. When I tried to use its help feature, I got an error message, "Navigation to the webpage was canceled." I searched the database and didn't find anything, so I sent Scooter Software an e-mail about that.

The folder comparison feature was very smooth. Folders were color-coded according to whether they matched or not. Black folders matched -- that is, they were identical. Other colors seemed to indicate some degree of mismatch. Lacking the help feature, I looked for a user's manual on the website. All they had was a bunch of knowledgebase articles. I'm sure these were very helpful for some purposes, but their titles revealed none on the subject of folder contents or colors. Nonetheless, when I clicked on a purple folder, I saw that only one of its subfolders differed. Eventually, I found that I could actually configure my own preferred colors for the following statuses: same (i.e., the folders in the two comparison panes are the same), orphan, older, newer, and different. There were also color options for file comparisons.

Cool feature: when you click on a folder on one side of the comparison screen, the problem automatically opens the parallel folder on the other side. In other words, I'm looking into a subfolder on drive F, and it's opening up that folder for me; but at the same time it's also opening the comparison subfolder on drive H. With just this much knowledge, within about a minute after starting to fool with the program for the first time, I was able to detect that there was one varying file, nested seven layers down, in a folder containing almost 30,000 files. As far as I could tell, the difference was that the filename for the one had been truncated.

One thing that I didn't find was the ability to reload an old comparison log and compare it against a new drive. For example, suppose that, on December 31, 2007, I burn a CD to archive some files. I compare that CD against the source folder on the hard drive. Everything looks good. Then, sometime during 2008, something happens and it appears that I may have lost some stuff from the hard drive. What did I lose? I don't know, because the hard drive has changed by now, and unfortunately I can't find the CD. Ah, but if I could run a comparison of the hard drive's current state against the previously saved log comparing the hard drive and the CD on December 31, 2007, at least I could know what might be missing and take appropriate steps to replace or compensate for it. Another scenario: I back up my data every year, and now I want to see a single list of all the changes in my folders since 2003.

About this time, I realized that I had not actually examined the support forums at Scooter Software. As it turned out, there were several hundred threads in those forums. Some of them appeared to be exchanges between the proprietor of Scooter Software and his chief programmer, but whatever; it was still good to see the effort and interest in the product.

There was a lot more that I wanted to try with Beyond Compare, but I was not quite set up for some of that, so this is where the matter stopped for the time being.