Ray Woodcock's Latest

Where to put the data ... hmm. I had a home network with two computers running Windows 7. If the data I needed to work with was on one computer and it went down or had one of those frequent Microsoft maintenance or service interruption needs, I couldn't get to it from the other computer. But if I put the data on a server, then (a) I had to buy and maintain the server, cables, routers, etc., (b) I had slower access times, (c) the data would then be unavailable to *both* machines (unless I wanted to swap out one or more hard drives) if the server went down, and (d) I had found that, if I accidentally corrupted or deleted the wrong file, a server might not be willing to undelete it. Not a big deal, assuming you had good backup, but there were painful exceptions.

So it occurred to me: can you put the data on one computer, so that it can function as a standalone, and also put the data on the other computer, so that it is a standalone too, but then have a constant RAID or mirror arrangement between the computers, so that whatever you do with the data on one computer is immediately duplicated on the other computer? That way, you've got local speed, no server, and redundancy during downtime on either machine. Basically, two-way mirroring: when a file is modified, it checks the other computer, and the two of them figure out which version is newer, and it overwrites the older version on the other machine as well. All you need is a router, if that.

I figured possibly everybody else already knew the answer to this. But since I didn't, I started with a search. Only six hits. It looked like the concept of "RAID between computers" was a nonstarter. Alright, a different search. Wow, "mirror between computers" produced 13 hits. But, OK, not to complain, it seemed most of those hits were for TreeNetCopy. Take it out of the equation, and the search produced only five hits. So TreeNetCopy seemed to provide the path forward. But it didn't look like CNET, PCMag, or other big-name sites had reviewed it. I went to the product's home website and found out why: it was for systems using Windows NT or Windows 2000.

Apparently mirror and RAID were not the concepts I wanted. How about incremental backup? You couldn't have it running constantly; it would have to finish one scan of the system's files before it could start on the next one. So maybe you'd set it to run every 15 or 30 minutes, or however a scan would take to finish, across the network connection. This wouldn't be nearly as good as software that would detect and propagate changes as soon as they were made, but I wasn't seeing how to find anything like that. With a 15- or 30-minute delay, you couldn't have someone being able to open the file on computer B as soon as someone else updated it on computer A, unless possibly if you had a script that would somehow be able to run the incremental backup manually for a given folder by just maybe choosing a right-click context menu option.

Alright, a different approach. I had been using Beyond Compare, a file comparison tool. It still looked like one of the more capable file comparison tools, so how about using it? As I was thinking about that possibility, I realized that I didn't like the idea of having to do a right-click or other manual update. The computer could crash before I got around to that, and then I wouldn't have the current data in the parallel folder on the other computer, and therefore really couldn't just keep right on working where I left off. I had only used Beyond Compare as a manual comparison tool, where I would start it up and it would run for a while and compare directories and then show me what needed to be mirrored to my backup drive, and then I would click the buttons necessary to do that. I knew it was possible to write scripts to automate some of this, but it seemed unlikely that scripts would help Beyond Compare remain up-to-the-minute on all of the file changes made on the system. Most likely, I could set up scripts to run in some frequently used folders, and maybe even to automate the mirroring of those folders, but other folders would be left out in the cold. Possibly I could have multiple scripts doing comparisons of more- and less-frequently used folders on different schedules, so as to increase the likelihood that most folders would be mirrored relatively often. But with enough scripts running simultaneous file comparisons, I'd start to take a performance hit.

Lacking a better option, I did a search to learn more about Beyond Compare scripts. The search came up with a number of interesting concepts, right there among the top ten hits. One was the concept of automated synchronization. Duh! Of course. Synchronization was the Windows term for what I wanted. So I did a search for that, dropping Beyond Compare for the moment. But the only thing that came of it was the discovery of Super Flexible File Synchronizer, which cost $60 for a two-year license (unless, for some bizarre reason, I would think that I could do without the pro version's ability to copy ZIP files!). It did look like it might have some advantages over Beyond Compare, such as the ability to detect that I had moved a folder, so that it could just repeat the move rather than delete the folder from one location and create it in another (which might involve a lot of copying, if it was a large folder). It had very good ratings on CNET. I could download and try it out free for 30 days. But it was ultimately still a backup program, running on a schedule, not a mirroring program, so I was still basically working with the same scenario: design a set of backup scripts, profiles, or whatever, and set them to run at different frequencies, backing up what I would consider the most heavily used folders most frequently.

TopTenReviews ranked Super Flexible File Synchronizer eighth in its list of sync programs. Their comparison page had a number of relevant criteria, including the ability to do bidirectional sync, to mirror files, and to operate across a network. It actually looked like their number two program, GoodSync ($19.95), had better features for my purposes than their number one choice, Syncables 360 ($39.95). Their review of GoodSync made it sound good indeed. They said it couldn't sync or merge Microsoft Outlook files, which was OK because I was using Thunderbird. (Later, I encountered a review by a user who said s/he was using it for this purpose, so I assumed they had updated the program.) They said that working over networks could be complicated. I wasn't sure if they meant that as a generic remark that would be relevant to all kinds of work over networks. They seemed to rank it number two rather than one because it "lacks some of the advanced features professional users expect." CNET's review likewise ranked it number two, but in the category of "file management." I wasn't sure what they considered the number one program; their webpage didn't indicate which criterion they used for that ranking. But GoodSync was the most frequently downloaded program during the prior week. GoodSync's awards webpage mostly listed awards and positive reviews that were at least a couple of years old. So apparently it had been created and was now coasting. I did a search among its many reviews on CNET, looking for more info about using it on a network. Unfortunately, CNET's links to specific reviews weren't working for me at that point, so I wasn't able to get details, but what I was able to read from the summary results was positive with the exception of one person for whom GoodSync did not work well.

There were hardware options. SyncSharp offered a device that would synchronize via USB. It sounded similar to The Tornado and to the Windows 7 Easy Transfer option. I didn't want an additional device, and since ethernet was faster and was already in place, I didn't want to use USB. For purposes of speed and also capacity, not to mention reducing dependency on external data sources, I was obviously not going to be interested in a cloud (i.e., web-based) solution, even if I had found one that offered constant, continuous, real-time synchronization.

It turned out that CNET had another category, for "data transfer & sync software." As with some other CNET searches, I looked at the top 30 both in terms of downloads last week and user ratings. Setting aside those that were for special purposes (e.g., Blackberry, Outlook), and focusing on those that were for Windows 7, I found that only two were free: CopyTo Synchronizer, which had only two votes and which I therefore deemed insufficiently tested, and Microsoft Live Mesh, which had only one vote but which I was willing to assume was better developed. The nonfree alternatives that came up in this search included BeyondSync, ViceVersa Pro, Easy Computer Sync, and Syncables 360 Premium. I reduced this set to Live Mesh, Beyond Sync, and ViceVersa. A search for further information on Live Mesh suggested it was web-based, more like DropBox, leaving me to focus on the other two. A search led back to a TopTenReviews comparison -- it may have been the same one as before, but a couple of weeks had passed by thie time -- naming GoodSync (above) as No. 2, ViceVersa as No. 5, and BeyondSync as No. 10. Of the ten, the ones offering bidirectional sync, network synchronizing, and Windows 7 support were these three plus Syncables 360, SugarSync, Laplink, and Super Flexible. Most of the same names also appeared in a CEOWorld review. I eliminated SugarSync as another cloud solution. The TopTen review for Beyond Sync made it sound unappealing. A dotTech review echoed that.

I ran a search looking for comparisons of Syncables against the others that also sounded good for bidirectional synchronization. A couple of reviews alerted me to the feature, evidently present in GoodSync but not all others, of being able to see which changes would overwrite. I began to get a sense that Syncables was more of a glossy product, designed for people who wanted simple and trouble-free synchronization without necessarily having an option to scrutinize every step of what was happening. Having been burned by the occasional backup program that would not save (and would also not tell me that it was not saving) files of a certain kind, or nested too deep, or had an umlauted character in their filenames, or were otherwise secretly exempt from what I thought was happening, I had become more inclined to use transparent software. At least until I gained a lot of trust and experience with a program, I wanted to see what it was doing. So this feature of GoodSync appealed to me. I noticed, also, that a review described Liuxz Sync as being "of most use to users that need to carryout real time synchronizations over a network or between hard drives." As I continued to look at other opinions, ViceVersa still sounded relatively good too.

On this basis, I decided to start with GoodSync, as described in a separate post. After some days of using it, and comparing its results against an external backup drive via manual comparisons using Beyond Compare (as described in more detail in that other post), I concluded that GoodSync was a good product for this purpose. I set its sync rules so as to check most frequently those partitions in which I was most likely to make changes. For practical purposes, I could change files on one computer and I would see those changes on the other computer when I went looking for them.

In short, I wound up using GoodSync to synchronize files on two computers on a home network. The files were generally available on the other computer within minutes. I did this without using a server. That is, the files were available locally on each computer, so that I could keep right on working if the other one went down. I arranged backup via external drive, and I occasionally checked that external drive against the internal drive manually using Beyond Compare. I had better performance than on a network, and was not very vulnerable to network problems; presumably I could have set up the same arrangement via crossover cable, without even having a router. This really felt like a solution that I had been seeking for years.

As described in another post (posted about the same time as this one), I decided to try GoodSync to keep two desktop computers running Windows 7 in constant synchronization. This post describes how that worked out. As with my other posts, this post presents the actual process, in all its chaotic glory. This seems to be a good way of conveying what it was actually like to install and use the program.

I started by going to GoodSync's homepage to see if their description made the program sound like what I needed. On their Features page I noticed, among other things, that "Analysis and Synchronization can be started when any file in sync folders changes." I saw that GoodSync also came in an Enterprise version with appropriate features (e.g., command line) for $10 more. The download page (for the Pro version) offered versions 8.5, 9 beta, Mac, and portable. I would have gone with the portable version, if I had had a more consistently good experience with other portable software -- after all, why not avoid having to reinstall a program on each machine? It was a little confusing -- they seemed to offer a separate trial version -- but on the assumption that I would just have to enter a license key within 30 days, I downloaded Pro version 8.5. (I later found an indication that the portable version would not start automatically with Windows and could not be scheduled via Windows Scheduler. There was no user forum on the GoodSync site.)

I had set up a home network, so I knew my computers were seeing each other. I had also done full backups on both computers to an external drive that was now disconnected, so I was confident that even the worst screwup could not completely trash anything irreplaceable. In fact, I went ahead, using Beyond Compare, to synchronize those backups with each other. So both computers, at this point, had identical data. So I could change just one thing and see what happened. (My impression of Beyond Compare was that it could have done much of the same thing as GoodSync, but would have required me to write scripts to do it. If I was going to write scripts, I would just use the Windows equivalents of rsync and cron.)

With that in place, I installed GoodSync on one computer and ran it. It opened a dialog inviting me to set up my first job. I had a choice of synchronizing or backup. The interface was like other file comparison software, with two panels side-by-side representing the two computers being synchronized. I needed to indicate what I wanted to synchronize. Unfortunately, it wouldn't let me designate all of computer A. As I confirmed at their FAQs page, the best I could do was to set up separate jobs for each individual folder off the root drive! So if I created a new root folder (say, D:\Newfolder) and forgot to set up a new GoodSync job for it, it would not be synchronized; likewise if I changed a root folder's name. Apparently files stored in the root folder could not be synchronized in any case, unless perhaps one went to the trouble of mapping that drive and attempting a sync on the map. I nearly dropped the program at this point. I did try synchronizing drive D, but the OK button was grayed out when I selected that. (Later -- after I had set up and configured individual jobs for each of a dozen different folders -- I went back and tried drive D again, and this time it worked. I wasn't sure what happened there, but I spent the better part of an hour unnecessarily pursuing that. When I looked at the FAQs page again at that point, I realized they were talking specifically about drive C. Apparently they meant that other drives were fair game.)

Anyway, I went ahead with the experiment, creating a job for just one folder. I called it D-Miscellany, since it would be synchronizing D:\Miscellany. It was easy enough to indicate that folder on computer A, where I was working: the list of drives on computer A came up by default. But how to designate D:\Miscellany, the matching folder, on computer B? When I clicked the Browse button for the right-hand pane, it showed me just that same list of drives on computer A. The answer was that I had to look in the left side of the "Right Folder" dialog that came up when I clicked on Browse. I had to tell the program to look, not on Local, but on LocalNet SMB. It was greyed out at first, but I guess after computer A detected computer B, the LocalNet SMB option became available. But when I went there and tried to select computer B, I got an error: "Access is denied. (error 5)." So, referring back to the struggles near the end of my post on networking, I applied to computer B the same steps I had applied to computer A, so as to make its drives available to GoodSync. The starting point here was to right-click on drive D, using Windows Explorer on computer B, and go into Properties and tinker with the Sharing and Security tabs. In the Sharing tab, it was Advanced Sharing > Permissions > Full Control for Everyone. In the Security tab, I had to click Edit > Add > type "Everyone" > OK > Full Control (with Everyone selected) > Apply > wait > OK. That enabled me to put computer B's Miscellany folder in the right-hand pane of GoodSync. Next, I clicked GoodSync's Analyze button. It reported that the two were "In Sync." Good. Sync!

OK, so would GoodSync automatically detect a new file in D:\Miscellany on computer B, or would I have to click the Analyze button manually? Perusing the menu options, I saw that perhaps I could just click Job > Synchronize All without having to go through a separate Analyze step, but I wasn't sure about that. I went into Job > Options. Lots of things I could adjust if I wanted. This looked good. There was an option to do an Analyze or Sync (or both) every ___ hours and ___ minutes (fill in the box). So conceivably I could set the sucker to run every minute. I tried that. Clicking the Sync option there automatically turned on the Analyze option as well, so apparently Analyze was the necessary first step. Logical. I set it for zero hours and 1 minute. But then I deselected that and checked the "On File Change" box instead. Did this mean it would sync a file as soon as it was changed, on either computer? Time to try it out. I selected On File Change, clicked Apply, and then created a little text file on computer B in D:\Miscellany. I called it Test.txt. GoodSync on computer A said, "Analyze is blocked by Options or Browse dialog. Oops, OK, I clicked OK to close that dialog. The error message didn't go away. I had to close it manually. Ten minutes later, it still hadn't done anything. So I clicked on the Auto button on GoodSync's lower panel. That just brought up the Options dialog again. Alright, well, skip that. I unchecked the Sync and Analyze options for "On File Change" and went back to the option of synchronizing every 1 minute. That did something! Almost immediately, I got an indication that it had detected that something had happened with Test.txt on computer A. I went into computer A's D:\Miscellany folder and, sure enough, there it was. I changed its contents and closed it. Within about 20 seconds, Good Sync did something. I checked on computer B. Yes, its copy of Test.txt now had the change. Very good. I renamed the file on computer B, watched GoodSync react, and checked D:\Miscellany again on computer A. This was working. Note that the time on my computers did not precisely agree. Apparently GoodSync had made a note of that, and was adjusting its calculations accordingly.

As I browsed GoodSync's FAQs, I saw that they also did not automatically allow system and hidden files to be copied. I got the feeling that I had really better just double-check whatever GoodSync was doing with Beyond Compare, for a while, to make sure it was doing what I thought it was going to be doing. I didn't know what other exceptions there might be, and that's the point: I didn't know. I couldn't be sure. Even after reading the FAQs, as experience with other backup programs had taught me, there might be something else that the programmers decided not to include.

A couple of reactions, at this point, about the interface. One was that I wished that GoodSync were capable of more compressed viewing. There was a lot of white space among lines, such that relatively few files being compared were visible onscreen at any one time. Also, I wanted the Log Window to be more user-friendly. I think, instead of using up that valuable real estate with tiny print stretching across the full width at the bottom of the screen, showing only the last few lines, it would have been better to provide a more readable version behind a button, and to organize relevant options (e.g., show all errors) around that pop-up. Eventually, I also found myself wishing that, when I excluded a folder from consideration, it would automatically roll up into one line (i.e., no longer display all its subfolders and files) and change color or otherwise be marked as visibly excluded, so that it was not distracting me and taking up screen real estate. Also, it was odd not to have a save option of some sort on the Job menu. It seemed like some items from the Tools menu belonged on the Job menu, and vice versa. On the Tools list as it was, I assumed at first that "Export Job List" meant that it would save, to a designated file, the whole setup -- all of the jobs and settings that I had opened, exactly as the whole screen was now set up -- but later it occurred to me that maybe this meant, literally, only the list, such that I also had to do a separate save operation for the individual jobs. This was not something I wanted to get wrong, but it was also not something I wanted to spend more time researching. I guessed this was like Beyond Compare's idea of saving individual sessions within a workspace, and being able to save and load workspaces, but here it wasn't as clear.

For the time being, I closed the GoodSync window. It retired to the system tray. I could right-click its icon down there to reopen it. I did that. I adjusted its Tools > Program Options. There were pop-up help dialogs for the various settings, and these were generally pretty good. They needed to be gone over by an English major, though, with some attention to clarity of references. For instance, one said, "If checked then GoodSync will create left/right sync folders if they are not present." I had no idea what a left/right sync folder was, and there was no link there. I didn't want to lose my place, as I was going down through that help dialog, so I ran a Google search to get an explanation. The only search result with any information was for the GoodSync Manual, but it just repeated what was in that help dialog (or maybe it was the other way around). There was no explanation anywhere, as far as I could tell, of what a sync folder was. I gathered, from several oblique references, that GoodSync would optionally create a sync folder in each folder that it was synchronizing. To test this, I turned on the option to create sync folders, added a new file to D:\Miscellany, and sat back to watch. Sure enough, both computers now had a system folder called D:\Miscellany\_gsdata_. Needless to say, I didn't want that clutter. I turned off the option and made a change to my test text file. GoodSync mirrored it without complaint. This did not mesh with the manual's indication that there would be an error message if the sync folder was not found. Oh, but now I saw that was probably because unchecking the option did not remove the sync folder. OK, well, then, with the option off, I deleted _gsdata_ from computer A's D:\Miscellany folder and then changed Test.txt again. Whoa. _gsdata_ was back. Alright, what if I deleted it on both machines?

This called for a pause to reflect. Each synchronized folder would have a _gsdata_ folder. It would not be hidden from me, since I normally displayed hidden folders. But its presence would be a relatively minor irritant. After all, I had overlooked the intrusions of desktop.ini and Thumbs.db for years. I was not sure why GoodSync could not store all of that synchronization data in a cache, in a location of my choosing, as other programs (e.g., Copernic Desktop Search) would do. But if I had a good synchronization solution here otherwise, I would much rather have these headaches than deal with a program that did not do its job as well. Another concern was that I wasn't entirely confident that GoodSync was going to do the job right. I was not sensing a commitment to give me a transparent, thorough synchronization that I could trust without having to check up on. Still, it wasn't a backup program per se, so possibly this would work out OK. I would probably just have to use it for a while, to see how things turned out in practice. (If I do not comment on this program in future posts, it is likely that I stopped using it.) (This concern about the _gsdata_ folder was reduced, later, when I was able to synchronize whole drives rather than individual folders. At that point, the only _gsdata_ folders were in the drive root, i.e., at D:\ and E:\.)

I decided to continue. There wasn't much else to comment on in Tools > Program Options at this point, except to say that they did have a global Filters section there, so they surely could have allowed for folder filtering. Over in Job > Options, I noticed that they had an option to save one or more versions of deleted files for as long as the user might wish, or until disk space was gone. There was another, job-specific Filters option here. I didn't want exceptions popping up in my Beyond Compare double-check, so I didn't set filters; Beyond Compare would notify me about everything. (Somewhere along the way, I noticed that the contents of the help or explanation window at the bottom of these options dialogs would change as I moused over individual settings. This was very practical and helpful.)

Moving on, I was now back at the Job > Options > Auto section. The option of running a synchronization every ___ minutes seemed sufficient, so I didn't go with any of the other scheduling options. This D:\Miscellany folder rarely changed. I could probably set it to sync every couple of weeks, and just use GoodSync's manual Sync button if I happened to think of it after I did make a change in that folder. There was an option not to do a sync if more than a specified percentage of files changed. This, they felt, could be a sign that something was wrong and that manual intervention was appropriate. I decided to leave that at their default 10% setting, to see if that worked for me. Finally, there was an option to "Auto Clear the tree after Sync or Analyze with no changes." I had no idea what this was about, probably because I didn't know what tree they were referring to, and the help file did not provide an explanation. (I have pointed GoodSync to this post. Hopefully they will read it and address some of these concerns. If so, perhaps they will even post a comment to say so.)

Job > Options also offered Scripts and Advanced sections. In the Advanced section, I checked some things they had not checked, for added file integrity. In a case of "ask and it shall be given," I saw that they did have a job-specific "No _gsdata_ folder" option. The context-specific help note was too big for the little window at the bottom of the dialog, but I found it repeated in the manual. It said this:

No _gsdata_ folder (un-checked by default)

If checked then do not create _GSDATA_ folder in the Right (remote) sync folder of the job, instead create _GSDATA_ folder in the GoodSync profile folder on this computer.
If not checked then create _GSDATA_ folder in both sync folders of this job.
Still use _gsdata_ folder on the left side of the job.
Use this option only for folders that are not sync centers (all jobs only read from this folder or only write to this folder).
If _gsdata_ folder is disabled then these options are disabled too: Save Previous/Past Version.

This was not entirely clear. It seemed to be saying, for one thing, that if I did opt to save deleted copies of a file, those copies would be saved in _gsdata_. Possibly this was the reason for putting the _gsdata_ folders within the individual folders rather than in a separate cache folder: copying or moving them from their folder of origin to a cache folder could take a lot of time, in the case of many or large files. It still seemed like something that users should be able to choose, though. This message also seemed to say that, if I did opt out of _gsdata_ folders, my drive C would swell as I larded it down with data files from synchronized folders on other drives. Even after opting out, the program would apparently create a _gsdata_ folder in computer A nonetheless. I didn't know what a sync center was, it wasn't explained in the manual, and the parenthetical explanation here wasn't clear. I decided not to opt out of _gsdata_.  Finally, I changed their folder and file links options to "as is."

Whew. OK. I had set the options for the D-Miscellany job. Now I had about ten more to folder jobs to set up. That was going to be a pain, and the odds that I would get all the settings right without overlooking anything were just about nil. I would have to adjust timing for different folders, but otherwise most of their settings, it seemed, should be the same. I wished GoodSync had an option, like Beyond Compare, to set default settings for all jobs, so that I wouldn't have to do the same things for each job individually. Then I noticed an option to create a job template. Just what the doctor ordered. I wanted to save D-Miscellany as a template, where all I would have to do would be to change the folders being synchronized. To do this, I went to Job > Save as template. The location was C:\Users\Administrator\AppData\Roaming\GoodSync\Templates. I assumed I would have to make a manual copy of the resulting Default Template.gst file to my D:\Installation\Saved Settings folder if I wanted it to survive a Windows reinstallation. To use the template, I went to Job > New > From template. I soon found I could just click the yellow plus symbol at the left end of the tab bar to invoke this dialog. I was able to drag tabs into a preferred order, which was a nice touch. Specifying the folders to be synchronized took time: the computer apparently had to re-connect with the network each time I clicked on a Browse button. Each recognition step, two per job, took about 10 seconds on the left side and about 20-30 seconds on the right. Not much in the grand scheme of life, but a drag when you're creating a dozen or more jobs. This made me wish I had been able to just right-click on a static (refreshable) list of folders to create a job. Then I went back into each job and changed how frequently it would do its auto-sync. I decided to try again with the auto sync "on file change," reasoning that surely that part of the program must be functional, if not instantaneous. What I found was that it would check for file changes frequently -- every minute, from the looks of it -- so this was not the way to minimize system resource usage. So I changed them all back to a specified number of minutes after all. When I was done with this, I went to Tools > Export Job List and saved the .tix file to D, again to survive a Win7 reinstallation.

While I was doing all that, of course, those newly created jobs, modeled on D-Miscellany, were all springing into action to synchronize computer A with computer B. I had done a few file moves on computer A since using Beyond Compare to synchronize computer A with an external drive. So in a few moments I would go into Beyond Compare and compare computer A against that external drive again.

But first, something weird was happening. I had finished setting up the folder comparisons on the folders in drive D, but had neglected a couple of folders I had on drive E. When I began to set those up, I discovered that GoodSync would, in fact, allow me to do a comparison of the entire drive, rather than having to designate individual folders. This was what I wanted, but it was what they had said they couldn't do and what I had not actually been able to do on drive D. I went back and reviewed the FAQ page statement cited above. Well, it said that I could not back up all of drive C. It didn't say anything about drives D, E, ... So had I made a lot of extra work for myself -- was there actually a way of doing all of drive D at once, some way that I had just overlooked?

At this point, I discovered that GoodSync did have a right-click option to exclude the Recycle Bin and other items. Unfortunately, when I used that option, it ignored me.  There continued to be a yellow exclamation mark on the tab for that drive, and I continued to get error messages indicating that access to the recycle bin was denied. A yellow banner said, "Sync has finished with Errors or Unresolved Conflicts," and the log said, "Click Errors button to see sync errors." But there was no Errors button. I stopped GoodSync during a sync, so as to hunt for the log, but that made the program crash. It sent off a crash report to the GoodSync people.

Alright, then, this was a good time to do that comparison with Beyond Compare. I was not pleased with the results. Changes that I had made on computer A, after synchronizing via external drive with computer B, had been undone. That is, computer A had been restored to the earlier condition represented by computer B. The specific problem seemed to be that files I had deleted on computer A had been restored to computer A from computer B, instead of being deleted from computer B. Those may have been the only sync problems.  I restarted GoodSync and checked the file deletion settings. In Job > Options > General, I had already checked "Propagate Deletions," which should have taken care of it. In Job > Options > Auto, in response to "Automatically resolve conflicts," I had designated "Do Not Copy" instead of "Left to Right," "Right to Left," or "Newer File Wins." I changed this to "Newer File Wins," which was my preference, now that I thought of it, but this did not seem to explain the problem. I had not checked "Auto Clear the tree after Sync," and was irritated that the list of changes would disappear from the screen before I had a chance to look at them (if, that is, it ran another sync before I looked at the program again). Oddly, it seemed that computer B, where I was *not* running GoodSync, wound up with the correct files.

In short, my impression at that point was that there were some bugs in the program. At this point, I was wishing that Beyond Compare offered a sync program. But after that first scare, GoodSync seemed to behave more as I had expected. Hopefully this did not mean that it finally won and was able to delete the file versions that it did not like, that I happened to prefer.

I was not sure exactly what happened in that first encounter. It may somehow have been my fault. During the next 48 hours, GoodSync won my confidence. And then I used it to compare an existing partition with a new one, where I had added just a few programs on the new one via USB jump drive, and a similar thing happened again: the Analyze screen indicated that it was prepared to wipe out the existing partition and replace it with the new one. Then I realized that, of course, it should: the new partition had been changed more recently. It didn't go through with it, though, because it detected that more than 10% of the partition was going to change. So this was more like a warning to me, to not treat GoodSync as a magic wand that would automatically make everything right.

After several days of usage, with careful comparisons of all changes against an external backup using Beyond Compare, GoodSync seemed to be a solid, reliable way to keep two computers synchronized.

Users

I had installed Windows 7 on two computers. Here, I'll call them computer A and computer B. Both were connected in a basic wired network by ethernet cable to a router. The router I was using was a Belkin Connect N150, model no. F7D5301. I did not then know of the possibility of turning my computer into a WiFi hotspot, but I probably would have gone with the purchase of a router even if I had known of it.

I wanted to make the computers visible to, and able to share files with, one another. I also had a laptop running Vista and an old Windows XP desktop. This post describes the steps I took on the software side, after sorting out prior hardware issues.

I started with just computers A and B connected to the router. I ran a search, but it seemed like most of the webpages that were coming up had to do with troubleshooting. I wasn't smart enough to get into trouble yet. But then, as I started looking at some of those sites, I wondered whether possibly the computers were already visible to one another, merely by being connected to the router and not complaining about any IP address conflicts or anything like that. In Windows Explorer on computer A, I clicked on Network. I got an error up by the menu bar:

Network discovery and file sharing are turned off. Network computers and devices are not visible. Click to change.

So I clicked and selected "Turn on network discovery and file sharing" and chose only the home network (not public) option. Within about 30 seconds, Windows Explorer on computer A was showing both computers. Well, that was easy. So now I ran the router's setup software on the Vista laptop and on the WinXP machine, and then plugged them into the router. I changed the WinXP machine's name and rebooted it.

Changing that name left an outdated entry for the WinXP machine's previous name in the displays on several computers. On the WinXP machine, it produced an error message: "[Oldname] is not accessible. You might not have permission to use this network resources." The outdated entry wouldn't go away when I refreshed (F5) the view. Note that I was still down in the Network section of the Windows Explorer folders pane. I was not using the Homegroup option up topside.

At this point, a search led to the advice to go into my router's firmware, via its built-in webpage, and look for a way to configure its list of devices. Apparently that's where the old name was being stored. Finding that place in my router required me to go into its installed software. Doing that required me to reinsert the Belkin CD and try to run the router utility from there, because the link that its installation had added on my Start Menu wasn't working. It looked like the CD was apparently only for simple installation purposes, either reinstall the software or quit. Eventually I figured out that Belkin expected me to have auto-play running on my CD drive, else it would not show me the option of going into its advanced features option. So I went into Control Panel > Autoplay. But there, I saw that Autoplay was already on by default for all devices. I had only noticed the advanced features option by accident -- I left the CD in the drive when I rebooted the machine after an update of some other software. Taking another approach, I downloaded an upgrade of the router's software, installed that, and used its Advanced Settings option to get into the router. Once there, though, I did not see any entry for the old computer. By this time, though, a couple of hours had passed -- I had been working on something else -- so maybe the router refreshed itself. Hitting F5 to refresh the Network entries in Windows Explorer showed that they, too, had forgotten that old machine by now.

At this point, the two computers (A and B) running Win7 were showing Network entries for all four computers, plus administrators on computers A and B, plus the router. The Vista laptop and the WinXP machine were seeing the Win7 computers, but not each other. Oddly, the router's DHCP client list was showing the names of three computers, but not the Vista laptop. The Win7 computers were able to go online; the others were not, even after a reboot. So far, networking in Win7 was looking a lot easier than it had been in Vista or XP. I wasn't interested in investing a lot of time in this, and I had been thinking of dismantling the XP machine, so probably that would be the solution to part of this networking problem.

To summarize, networking in Windows 7 appeared to be a matter of plugging computers into a router, maybe fiddling with the router's settings or upgrading its software (neither necessary in this case), and turning on network file sharing when that option came up. Networking problems with Vista were still an unknown. I had previously been able to just plug the laptop into the router and go online, and had not tried to share files among other computers. But then I noticed that someone (I) had set the TCP/IPv4 settings on the laptop to something other than automatic. That took care of it. The Vista laptop saw everything. Its eyes were opened. That solved the problem for the WinXP machine too.

The remaining question: was I actually able to do anything among these computers? On computer A, I double-clicked on the icon for computer B. It said,

\\Computer B is not accessible. You might not have permission to use this network resource.

I searched on that and, as recommended, went into Control Panel > Network > Change advanced sharing settings > Home or Work (in the Win7 computers). There, I made sure everything was on except password-protected sharing. The only change I actually made was to turn off the requirement for a password. And that did it. Computer A was now able to see the contents of computer B. A similar change on the Vista laptop had the same effect.

Now I could see "Users" or "Users Share" folders. How to get full access to one computer's contents from another? The first step seemed to be to right-click on a drive or folder, in Windows Explorer, and choose Share with > Advanced sharing > Sharing tab > Advanced sharing > Share this folder. I did that with one drive on computer A. I tried to view it on computer B, but I got an error:

Windows cannot access \\ComputerA\SharedFolder
You do not have permission to access file://computera/SharedFolder. Contact your network administrator to request access.
For more information about permissions, see Windows Help and Support

I clicked on the Help and Support link. It said this could be because

You haven't created or joined a homegroup
You're not using a homegroup, and the folder or printer you're trying to access has not been shared
Network discovery is turned off
Password-protected sharing is enabled
The computers aren't in the same workgroup
Your computer doesn't have the latest updates for your router

Of these, it was true that I hadn't joined a homegroup; I wanted to see about doing it without, primarily because I had seen a few notes of people having complaints about homegroups. The folder had been shared. I had turned on Network Discovery and password-protected sharing. I had now installed the latest downloads from Belkin for the router. I tried to access \\ComputerA\SharedFolder from the laptop. Same error message -- except that, instead of pointing me toward Windows Help and Support, it said this:

No more connections can be made to this remote computer at this time because there are already as many connections as the computer can accept.

That sounded like old-school networking voodoo. I didn't want to go there. I just wanted the computers to link up. I decided to try the homegroup option, since that seemed to be the only option that might help. I reasoned that Microsoft had probably created the homegroup thing because the non-homegroup approach to networking was such a cluster. Ah, but then I discovered a possible reason for that last sentence in the Vista error message. I had set the Advanced Sharing properties > "Limit the number of simultaneous users" option to 2. I thought that was probably all I would need. I tried setting it to 20, where it was before. While I was there, I clicked on the Permissions button and gave Full Control to Everyone. I closed out of there and took another look in these other computers. Now I got more error messages. On computer B, the attempt to look at \\ComputerA\SharedFolder gave the same error as before. But on the Vista laptop, it produced this error:

Windows cannot access \\ComputerA\SharedFolder
Check the spelling of the name. Otherwise, there might be a problem with your network. To try to identify and resolve network problems, click Diagnose.

I did that. It came back with this:

\\ComputerA\SharedFolder is available but the user account that you are logged on with was denied access.

Well, it was true -- as I discovered, back in the Advanced Sharing properties dialog -- that if I clicked the Caching button, I got a new option that said this:

All files and programs that users open from the shared folder aer automatically available offline

But I decided that meant that files from computer A would be copied to computer B and stored there somewhere, if I looked at them on computer B. I didn't want that. I had enough clutter already. I set the caching to "No files or programs from the shared folder are available offline." I tried the reciprocal step of setting up a partition on computer B, to see if it would be available on computer A or on the laptop. No joy.

I came across a webpage that made me think perhaps I hadn't explored the requirement (above) of making sure the computers were all on the same workgroup. In Control Panel > System > Computer Name on the XP machine, it was just WORKGROUP. Same thing on the laptop and the Win7 computers. So that wasn't the explanation.

So, OK, maybe it was time to try homegroups. On computer A, in Windows Explorer, I went to the Homegroup link at the top of the folders pane. That opened up an option to join the homegroup that Windows detected already existing. I did that. It told me I needed to get the password from Ray on computer B. That was odd, because I was Ray, and I didn't have any such password. I also didn't want the homegroup to have a password. It was just me here.

Upon seeing a page that showed something different from what I was seeing, I decided to back up here. Before going on to the homegroup option, I noticed that, when I right-clicked on the drive I wanted to share and selected "Share with," I wasn't seeing a list of groups or people. But, ah, when I clicked on a folder instead of a drive, I did. Hmm. But surely it was possible to make a drive visible to other computers?

I did a search and found a thread where people were having exactly the problems I've described here. At this point, the last post in that thread suggested starting with Start > Run (or just type) fsmgmt.msc. I did that, on computer A. I went into Shares and double-clicked the drive I was trying to share. This gave me pretty much the same stuff as before, except in its Security tab. There, I selected Users > Edit > Full Control > Apply. I clicked back and forth a couple of times to make sure it took. The first time, it didn't. I okayed out and tried again to access this drive from computer B. No luck. But now I wondered what kind of user this was, this person on another computer. The answer seemed to be that it was an Everyone. In other words, the groups or users presently listed in that Security tab were Authenticated Users, SYSTEM, Administrators, and Users; and since those all had full permissions and the person (me) trying to access computer A from computer B *still* couldn't get on, apparently I had to be in the Everyone class. So, as advised, I clicked Edit to add Everyone, and then gave Full Control to Everyone > Apply > OK. This would have been just as easy to do back in the drive > right-click > Share with > Advanced dialog, actually. Now that Everyone was allowed to see everything, surely someone on computer B would now be able to see the contents of the shared drive on computer A. And it worked. Woo-hoo! So the missing part here was that I needed to add Everyone in that special place.

It was getting late, and I'd had too much fun for one evening, so I decided not to press the point and work through it with all of the machines. I had faith that this was approximately the answer at least for letting other computers see what was on a Win7 machine, and that's all I really wanted to achieve here anyway, as I had nothing interesting on the laptop or the WinXP machine. There were some other interesting networking possibilities I was eager to get on with, as described in some other posts on this blog that I wrote up about the same time as this one.

I had a Linksys WRT54GL v. 1.1 router, running in Windows 7. The router did not seem to be functioning properly. I wanted to find out whether it was "bricked," as they called it -- whether some tinkering on my part, or some power surge, or something else had turned it into a useless brick, a paperweight. I wanted to get it back into service, if I could, and I also wanted to look into the possibility of upgrading its firmware while I was at it. This post describes the steps I took along those lines.

First, I followed a set of steps to see if the router was bricked. I disconnected all ethernet cables and plugged in its power cable, and let it sit that way, powered up but not being used, for at least five minutes. Next, I connected the router only to the computer that I would be using to examine its condition. I did not connect it to the modem or to any other computers. Then I started gathering basic information.

Gathering Basic Information

I went into Control Panel > Network and Sharing Center > Local Area Connection. In the Local Area Connection Status dialog, I clicked on Details. (I could have done approximately the same thing in a command ("cmd") box. To open a command box, I would have gone to the Start button and typed "cmd" into the "Search programs and files" box. In the command box, I would have typed "ipconfig /all.")

In that Network Connection Details dialog, I saw that I had the IPv4 address assigned by the router. By default, it was 192.168.1.100. I also saw that the IPv4 Default Gateway was 192.168.1.1. As far as my network was concerned, this (192.168.1.1) was the address for my router. I had not set it that way; this was the default address for this model of router.

I closed the Network Connection Details dialog and clicked on the Properties button, there in the Local Area Connection Status dialog. In Local Area Connection Properties, I scrolled down and selected Internet Protocol Version 4 (TCP/IPv4). I clicked on Properties. There, I saw that the computer was set to "Obtain an IP address automatically." So I knew that I had not manually instructed the computer to use 192.168.1.100. That address (192.168.1.100) was appearing in the Network Connection Details dialog (above) because the router was putting it there.

In short, the computer was connected to the router at the router's default address of 192.168.1.1. The computer was then obtaining its own assigned IP address of 192.168.1.100 from the router. The computer was set to accept automatically whatever IP address the router assigned.

I could verify that the router was indeed set to assign an IP address of 192.168.1.100. Indeed, I could change that address, if I had some reason to do so. I could do this by logging into an internal webpage hosted within the router itself. The router was my computer's gateway onto the Internet. As described above, the router's default gateway address was 192.168.1.1. I could go to that address using an Internet browser (e.g., Internet Explorer, Firefox). I just had to type those numbers, with nothing else, into the address bar of an Internet browser, and hit Enter. That would take me to the router's login box. By default, the username for this model was just left blank, and the password was "admin." If the username or password were forgotten, a reset would be the likely solution.

In the router's internal webpage, in the Setup > Basic Setup tab, I verified that 192.168.1.100 was the assigned "Starting IP Address." (Other computers on the network would automatically be given related but not identical numbers.) I could also have changed the router's Local IP Address at that point, if I had had some reason to do so.

Testing the Router

Now that I had this information, I could proceed. If I had gotten information different from that provided above, it might have been because the router was not working right, or because I (or someone else) had changed the default settings.

Now I could just verify that the router was definitely in touch with the computer. I had already done that by logging into the router's internal webpage. Instead, I could have just typed this into a command box: "ping 192.168.1.1" (or whatever the router's gateway address was). If it came back with a set of statements indicating that it had received a reply, then that meant that the ping had gotten a response from the router, so all was good. This situation could be compared against the alternative by unplugging the ethernet cable leading to the router. In that case, the "ping 192.168.1.1" command would produce no reply or some kind of error message (e.g., "Destination host unreachable").

Nonresponse from the router could just mean that there was something incorrect about the addresses being used. It could also mean that the router was bricked. Another clue would come from the power light on the router. If it was dimmer than the other front-panel lights, or if it just kept on blinking, that would be another clue that it was bricked.

I did not have these problems. But I was having problems that seemed to be related, at least partly, to the router. So I looked for more information on testing it. I found the so-called "peacock thread" on the DD-WRT website. Its Note 6 defined a bricked router as follows:

A bricked router is a router that you can no longer communicate with through wireless or wired connections. It will give no response. Just because a router doesn't seem to be fully working, doesn't mean it is bricked. . . . A brick will not respond to pings at all.

By this definition, my router was not bricked. I could communicate with it. It was just not fully working. Note 6 went on to provide further information. It referred to the TTL values produced when I typed "ping 192.168.1.1" (above). Mine was TTL=64. Note 6 said this meant that the operating system firmware on the router was responding. It sounded like some routers would deliberately start at TTL=100, which was apparently a slower setting more suitable for starting the process of upgrading the firmware, and would then switch to TTL=64. To ping continuously and see if things changed, the command provided above would get an additional -t. That is, the command would be "ping -t 192.168.1.1." Usually, if the firmware was not functioning, there would be no response. Other possible responses were TTL=1 (apparently the same as TTL=100 for these purposes) and "Destination host unreachable," which Note 6 said could be fixed by making sure the computer and the router were using the same static IP subnet. There were other possibilities. Note 6 summarized the situation thus:

Some routers can be bricked even if they do give some ttl=100 responses to pings, but this is less common. Some routers can be bricked if the lights are not all lit, but again, this is not common. However, if the lights are all lit, and you cannot get a ping response, the router is definitely bricked.

Again, it seemed clear, mine was not bricked. I was not clear what that meant. It wasn't working, but it also wasn't nonworking. It was working in the sense that I could get into its operating system, but not in the sense that it would actually function as a router. It seemed there were hardware and software versions of being bricked. I decided to upgrade the firmware and see what would happen.

The Hard (30+30+30+10+10) Reset

Since it didn't look like my router was bricked, the next step was to do a hard reset. They recommended doing this before and after every firmware upgrade. This began with an effort to verify where the reset button was. On the Linksys WRT54GL, there was a recessed reset button on the back panel, and there was also a concealed button behind the glowing Cisco Systems logo on the left side of the front panel. The manual was not clear on this. The button on the back panel seemed to be definitely a reset button. The one on the front might have been intended only to clear the SSID and WPA Personal keys.

Following instructions, with the router connected to nothing except its power cord, I pushed the rear-panel Reset button and held it down. After 30 seconds, still pressing the button, I unplugged the power cord. After another 30 seconds, still pressing the button, I replugged the power cord. After another 30 seconds -- a total of 90 seconds -- I stopped pressing the Reset button. Then began what they should have called the 10+10 part of the procedure: wait 10 seconds after releasing the Reset button, then disconnect the power cord again and wait another 10 seconds, then replug the power cord. I did all this. My power LED was not continuously flashing. I was ready for the next step.

Debricking the Router

I was visualizing some kind of cold shower or slap across the face -- something, anyway, that would deprogram the router back to normalcy, after which a person would then go ahead and fulfill the societal role of reprogramming with "correct" content. But at this point, it did not appear that there was any unbricking procedure per se. You just had to reset the router and then install firmware on it. I wasn't even sure what difference it would make if it was a brick: it seemed like a person would go through the same steps regardless, as long as s/he wished to upgrade the firmware. On this understanding, I passed Go, collected $200, and commenced onward to the upgrade step.

Preparing to Upgrade

DD-WRT offered firmware upgrades specifically designed for Linksys routers. The DD-WRT firmware options had features that did not seem to be included with the standard Linksys firmware. Most of these features seemed to be designed for networking freaks, but that obseration probably somewhat reflected my ignorance of what many of them even meant. A few did pop out at me, though. I thought it would be at least potentially useful, and might sometimes be important, to have features like bandwidth monitoring, a Connection Warning Notifier, a presumably improved kind of firewall, and perhaps a Samba client, since I had had problems getting Samba up and running previously. Wikipedia offered a pared-down list of what may have been the most important features.

Guided by the Wikipedia list, and by the advice that I should first upgrade with only the micro or mini versions of DD-WRT, I chose the mini. It had a few more features. I double-checked my router version on the DD-WRT hardware database. It said that versions 1.0 and 1.1 of the WRT54GL were supported. I went to the hardware-specific page for this router. I liked the idea of upgrading then again, from the mini to the VoIP, because I used Skype; but when I browsed the list of features, it didn't seem like the VoIP option had a lot of additional stuff to offer over the mini. (The features mentioned above seemed to be included in the mini.) So I decided a follow-up upgrade would come later, if at all.

It was a bit tricky to find the download. It turned out that what I had to do was to use the hardware database, enter WRT54GL, and then double-click on the results list (consisting of just that one item). It gave me three different versions of the Mini: generic, or for flashing by TFTP or web. The hardware-specific page said I should use the generic version if I was installing via web. The web-based approach looked like it might be easier (i.e., harder to screw up). I decided to use the web-based approach, so I downloaded the generic version (using computer B, which was not connected to the router, though I could also have connected computer A directly to the modem, bypassing the router, and downloaded it over there, which would have saved me the step of copying it over by USB flash drive). The hardware-specific page pointed me to a specific build fo DD-WRT, so I also downloaded that. I wasn't sure if I would use it, though, because I couldn't tell for sure if it was for the web or TFTP approach. It was also smaller than the generic one I got from the hardware database, making me think maybe the webpage promoting it hadn't been updated for a while. I used a USB jump drive and copied the upgrade files over to computer A.

For the web-based approach, they warned me to use Internet Explorer, not Firefox, though I noticed that someone said Firefox was fine too. They also advised making sure I had file sharing and could browse to see other computers on the network. This was not the case for me. I was hoping that the router could help me solve problems with my network, as described in other posts. They further advised making sure the computer's power options would not trigger the screen saver, or worse, during this process. Having reset the router (above), they advised to reboot the computer and log in to the router (above). I saw somewhere the advice to disable the Windows firewall, so I did that too (Control Panel > Windows Firewall > Turn Windows Firewall on or off).

There were some further recommended steps. One was to make sure I had everything I needed before I started, because of course I wouldn't be able to go online with the target computer -- which was one of the reasons why I found it advisable to have at least two computers. This bit of advice was especially important if, for some reason, a failed upgrade would mean the end of Internet contact from that workspace. I also had to disable security settings and programs. This included disabling antivirus (Start > search for Security Essentials > turn off real-time protection > Save changes); disabling Windows Defender real-time protection (approximately the same steps); turning off User Account Control (UAC) (Control Panel > User Accounts > Change UAC settings > Never notify > OK); and turning Local Intranet security all the way down (Control Panel > Internet Options > Security tab).

As advised, I planned to use a wired (not wireless) connection to the router. I enabled TFTP as a precaution (Control Panel > Programs and Features > Turn Windows features on or off > TFTP client). It seemed that I did not have to worry about Compound TCP, which was evidently disabled by default in Windows 7. I did not have to disable wireless (Control Panel > Network and Sharing Center), since I had not set it up in the first place.

Upgrading the Firmware

Now the game began. The router was connected only to computer A. I logged in to it on computer A at 192.168.1.1 (above) and went to Administration > Firmware Upgrade and browsed to the DD-WRT*.bin upgrade file that I had decided to install. I clicked Upgrade and left the room for a minute or two. When I came back, it said, "Upgrade is successful." I clicked Continue. I then noticed I was supposed to wait five minutes before clicking Continue. So now I waited. When the router's WLAN light was on (and I had the impression it came on pretty quickly), the upgrade was said to be complete. Nonetheless, I waited. When the minutes were up, I had to enter a username and password. According to the DD-WRT FAQs, the default username was "root" and the password was "admin." It seemed that I was safe in clicking the Continue button, because when I did enter the password, I got a warning:

W A R N I N G

Upgrading firmware may take a few minutes.
Do not turn off the power or press the reset button!

This part did take a while, especially because I thought I was supposed to wait there. Eventually it dawned on me that I should go ahead and click the Upgrade button that was staring at me. Did we not already do this? Apparently the concept was that I had last been in the Administration > Firmware Upgrade section, and now, after the upgrade, I had been returned to that same section. So, sure, I could go ahead and upgrade the firmware again if I wanted, but otherwise we were done. I was supposed to do another hard (30-30-30-10-10) reset, so I disconnected the ethernet cable from the router and did that.

There were a few things that I did not need to know, but might have needed under other circumstances. I did not need to know how to recover from a bad flash. I did not need to know how to put the router into management mode, so as to ease a command-line installation. There were tons of other instructions and information, but now that I had gone through it once, I thought that it probably could have been quite a bit quicker and more streamlined than it had been for me.

The Acid Test

On computer A, before going online, I now had to re-enable my security software. I connected the computer to the router and logged back into the router's internal webpage. The control panel still had the same basic arrangement as before, though sleeker. For the moment, I left it at the default settings. I connected the router to the modem. I still wasn't able to go online. Following advice, I went back to the router's webpage and made some changes. In Setup > Basic Setup, I changed Conection Type to PPPoE. That gave me an opportunity to enter my AT&T username and password. I clicked Apply at the bottom of that screen. After a minute, it had finished applying those changes. I tried again. Still no luck.

In short, upgrading the router's firmware did not seem to help computer A go online. It also did not seem to make any significant difference in helping computer A communicate with computer B. Both the router and a network switch were able to show the existence of the other computer, but not much beyond that. Tentatively, it appeared that the uncertain status of my router, going into this project, tended to predict an uncertain outcome. It was not really bricked, and therefore could not be saved; rather, it was just not working right, for some unknown reason, and all this effort could not change that.

I was becoming acquainted with Windows 7. Sometimes, when I booted it up, it would immediately recognize the other computer (running Windows XP) on my home network, and would also recognize the (Linux-based) Synology Network Attached Storage (NAS) device I had connected. At other times, unfortunately, the Win7 computer would only see itself. This post describes steps I took to resolve that inconsistency.

I did a search on this problem. I was inspired to undertake this investigation after I used System Restore to restore an earlier state of the computer. Those other devices were now not visible in Windows Explorer. They had been visible just a few minutes earlier. To my knowledge, I had not done anything that would have made those devices more visible, or less so.

When I searched, I noticed a post in which someone said that Windows 7 was also losing track of drive mapping after it went into sleep mode. I wondered if that was related. The previous day, the computer had magically mapped drive D, a network drive on the Synology NAS, without any instruction from me to do so. The poster said that he was experiencing both of these problems. That particular thread concluded without an indication of a solution. One poster said, "Ultimately this is just the nature of the way networking is sometimes." But it seemed to me that it had never been that way between the XP machine and the NAS, or between the NAS and the Ubuntu setup that I had been using before I got Windows 7.

I wondered if it was somehow an XP problem. The WinXP machine was currently in touch with the NAS. Was it possibly barring the Win7 machine from seeing either itself or the NAS? I rebooted the WinXP machine, but that didn't make a difference on the Win7 machine.

It wasn't a hardware problem, or even a networking problem per se. Access to the Synology unit was through a web-based program. On the Win7 computer, I could go into that Synology program and could communicate with the Synology NAS unit. Synology could see the NAS unit, but Microsoft couldn't. Apparently whatever was keeping Win7 from seeing the NAS was also keeping it from seeing the WinXP machine. It was all or nothing: either Win7 could see them both, or (as at present) it could see neither.

After going online in Internet Explorer and accessing the Synology NAS from the Win7 machine, I rebooted the Win7 machine. That did not make a difference. The Win7 machine was still unable to see the others.

In Control Panel > Network and Sharing Center > Troubleshoot problems, I tried the Incoming Connections option and said, "Find this computer on the network." It came back with this advice:

Reconfigure your network

To prevent problems other computers or devices might have when connecting to your computer, no more than one device should perform network address translation (NAT).

I followed the link into Windows Help and Support, but that wasn't actually too helpful and supportive. I clicked Next, and the Incoming Connections troubleshooter confirmed, "More than one device is performing network address translation (NAT)." So, OK, which device? I clicked "View detailed information" and went into Detection Details. All I could find there that looked like it might be informative was a Network Diagnostics Log. Following the links there in the Help dialogs, it seemed that, to open that up, I would have to use ThermaData Logger software. This software seemed to be almost completely unknown through the vendor, ETI Software, that Win7 pointed me to, but I did find plenty of links for it elsewhere. I had no idea why Microsoft required me to download a 29MB file from a slow connection just to read a log file. While I was waiting on that, I found ThermoWorks -- the need for using thermal logging software was another mystery -- and was right on the verge of downloading their ThermaData Software Suite for Windows when I looked back at the Help dialog and decided to try instead downloading ThermaData Studio 1.0.5, which was apparently an entirely different deal. That turned out to be a 12MB file. While that was downloading, I went back to the dialog and clicked on the "Other Networking Configuration and Logs" link to open NetworkConfiguration.cab. That led me to two text files: ipconfig.all.txt and route.print.txt. Neither contained any obvious references to NAT. I installed ThermaData Studio. Back in the dialog, I tried again on the link to the Network Diagnostics Log. ThermaData Studio wasn't going to read it right there on the spot, so I downloaded the log and tried opening it from there. But when I double-clicked on it, I got a message, "Windows can't open this file." I went into the Start Menu and opened ThermaData Studio from there and tried to use it to view the file that I had downloaded. At first, it didn't see anything -- it was looking for .msdb files -- but when I told it to look for .etl files, it found the download. It gave me a completely empty file. ThermaData Studio looked like solid software, but since I did not need it after all, I uninstalled it.

We were left with the question of which devices on my system were set to NAT. Trying another approach, I disconnected the WinXP machine from the network and re-ran the Win7 Incoming Connections troubleshooter. That didn't eliminate the NAT problem. I reconnected the WinXP machine, disconnected the modem from the router, and ran the troubleshooter again. Now the NAT problem was gone, though now there was a new problem, where the troubleshooter said it needed more information. So, OK, possibly the modem plus at least one other device was doing NAT on my network. I had seen a post indicating that modems and routers can both do NAT, so I plugged everything back where it belonged and looked at the pages on port forwarding and putting a router into bridge mode that that post linked to. Following what the latter seemed to be saying, I looked at a sticker on the bottom of my modem. (I didn't seem to have a manual for it, but could probably have downloaded one.) It gave me an IP address to enter into my Internet browser; and when I went to the appropriate page, it asked me for a code that appeared on that sticker. This led me into the configuration software for the modem. After poking around for a minute, I found a page for the modem's PPP location. This seemed to be what I wanted. It gave me two options:

PPP is on the modem. This is the normal mode for this modem. The PPP session is initiated from the modem.

PPP is on the computer, gateway or router. This should only be used if you need to run a PPPoE client on your PC or you use another device (e.g., gateway or router) to initiate a PPPoE session. This is often referred to as "Bridged" mode.

Since option A wasn't working for me, and since the post seemed to be saying that I should use option B, I switched to that and saved the change. This gave me a Location Warning. It said,

When using Bridged mode, your access to the modem becomes limited. To return to the DSL modem user interface after this change you need to directly connect your PC to the modem without any gateway or router between the modem and the PC, and configure your computer appropriately.

Configure the IP address of your computer to be on the same network as the modem by using an IP address of the form 198.168.1.x (except 192.168.1.254) and a network mask of 255.255.255.0.

You may also return to the DSL modem user interface by resetting the modem back to its initial defaults. All configuration changes and other settings will no longer be available if this is done. To reset the modem press the "Reset" button located on the back of the modem.

We still had a problem. The modem was supposed to be restarting, but it wasn't working. It had three green lights on, including the one for the ethernet (i.e., router). But why wasn't its Internet light on? I unplugged its power cord, waited a minute or so, and plugged it back in. That didn't help. I tried the same thing with its Internet (i.e., telephone) cord. When it was unplugged, the modem's DSL light was flashing red. So I seemed to have a mistaken understanding of the difference between its DSL and Internet lights. Well, whatever. It wasn't working, is the point. I thought that possibly AT&T (my ISP) needed the modem to be in the other mode. I thought about calling them to ask, but Christ, to enter again into that vale of tears: no way.

Well, I would have liked to research the modem situation further, but there was just one problem: I couldn't, as I now had no Internet connection. I ripped off the sticker on the back of the modem that said, "Remove only if advised by tech support" and there, in all its glory, behold: the Reset Hole. I jammed a paper clip into it and watched in amazement as this achieved ... nothing. It seemed the Reset Hole had gone stale. It took a couple of tries, and possibly the discovery that this unit required a minimum of 30 seconds of pressure in the hole to achieve the desired reset. Even so, I could get online only by cabling the computer directly to the modem. The router seemed to be dysfunctional. There was, inevitably, a call to AT&T after all, and it actually took only ten minutes

I went back to the modem's webpage, but was now getting "Unable to connect." Taking plan B, I cabled the WinXP computer directly to the modem, as advised above. But still, no joy. No Internet light on the modem; Unable to connect in Firefox. Now I had really done it. I had gone and given myself no alternative but to call AT&T. A half-hour later, we emerged with the discovery that I, in keeping with the spirit of the event, had lost my router password and unfortunately could not go online to figure out how to reset it, given that the reset button seemed to be having no effect no matter how thoroughly I massaged it. Oh, and the modem was back in its original mode. End of bridge mode strategy.

I ran a search on this reset problem. It produced some possibilities. One was that I needed to reset my TCP/IP preferences to match the router's IP address. Another was that I just wasn't following the right steps to reset it. Apparently it was too early to call it a brick; but even if it hadn't been, there seemed to be some kind of de-bricking option. Or maybe I just needed to go through the full set of steps for setting up the network properly. The part that I may have left out, in resetting the router, was that I did not disconnect all except the power cable before doing the reset. So I did that now, and held the reset button down for an overly long time. I replugged the cable between it and a computer. In the computer's web browser, I went to 192.168.1.1. This connected me to the router's webpage. The password to get in, after resetting, was admin. Now I set Wireless SSDI Broadcast to Disable. The webpage said I needed to initiate the push-button setup at this point. It seemed they were referring to the backlit Cisco Systems logo on the front of the unit; pressing it revealed that it was in fact a button, and this produced a message on the webpage:

Accepting clients!

You will be returned to the previous page after SES configuration completed.

It then did its thing for a couple of minutes, and then I was back at the webpage. The manual seemed to indicate that WPA2 Personal would provide the best available security for my setup. I enabled Wireless MAC filtering. The manual said that the option to Filter Internet NAT Redirection "uses port forwarding to block access to local servers from local networked computers." That sounded vaguely like what someone had said I needed to make my network work again, so I enabled it. A search led to the advice that I should not enable these until I needed them. I disabled Wireless Access Web, in this wired setting. A few more settings, and then I was done -- and still unable to connect to the router. The troubleshooter was going to be unable to give me much help, it seemed until I connected the router to the modem, so I did that. That still wasn't working, so I used the router's webpage Administration > Diagnostic options to ping the local IP address of 192.168.1.1. That worked, but was I just pinging the router itself? I tried 192.168.1.100. That worked too. I thought maybe the Traceroute diagnostic would be more helpful. It wasn't.

The manual gave some troubleshooting steps. Following its guidance, I made sure the router's light was solid green. The other instructions weren't applicable. For a moment there, I gave up on life. Then I ate a piece of chocolate and tried removing that NAT Redirection filter. That wasn't the solution, but it gave me enough cockeyed optimism to try the Internet Connections troubleshooter. It -- a veritable font of sharp-eyed discernment -- said this:

Your broadband modem is experiencing connectivity issues.

It said I had better power down the modem, wait 10 seconds until the lights were off, and then power it back up. I decided to also plug its cable back in. I was hoping that the troubleshooter would at least say, "Hey, we have found your modem -- so far, so good!" and I guess in a sense they did. With everything duly de- and re-powered and cabled, I tried it again. Now, by gum, we had a breakthrough:

Your computer appears to be correctly configured, but the device or resource (primary DNS server) is not responding.

What could this mean? I had no idea. I rolled the dice again on the Incoming Connections troubleshooter. While that was running, I realized that a minor miracle had occurred. Very quietly, while I was over there fixating on the Win7 computer, the computer on which I was writing this post had connected to the Internet -- through the cable, through the router, through the modem, through thick and thin! And ... er, no, it hadn't. Correction on that.

But at least there was a glimmer of hope. By this point in the day, I had moved away from the Windows XP system, on the second computer: I had rebooted with an Ubuntu live CD for maintenance purposes, and was therefore writing this post in Firefox on that machine while it endured its maintenance throes. And on that machine, for a minute there, I thought maybe it had made Contact. But it had not. I was in error.

Well, I had blown a good part of a day on a single troubleshooting problem. This was, thankfully, a less frequent experience than it had been in years past. I really and truly hated networking, and it probably showed, by this point, in my failure to grasp some obvious solution or to utilize some true-blue technique. I really had no clue. The problem wasn't with the modem or the Internet connection; I could save this post when I connected directly from the modem to this computer. Possibly the problem wasn't between the Win7 computer and the router; the troubleshooter had felt that everything was in place there.

Trying something a little different, I got an ethernet switch off the shelf and connected both computers directly to the modem through that. And, whoa, that changed everything instantly. The Win7 computer popped up a dialog asking me to Set Network Location, and it was immediately connected to CNN.com, and the Ubuntu live CD spun up and updated this text shortly thereafter. So. It was the router. I knew it all along. What could this mean? It could mean (a) the router was malfunctioning or (b) I did not have its settings right or (c) the real explanation, which I did not presently know. Putting my money on (b), I reconnected the Win7 machine to the router, went to its webpage, and chose the Administration > Factory Defaults option. When it was done wiping out all my hard work, it required the no-username, "admin" password entry. I ran the Win7 Incoming Connections troubleshooter again. It said it needed more info. I tried it again with the modem connected to the router. (CNN.com was not responding at that point.) This came back with the message about how the modem was experiencing connectivity issues.

We seemed to have the beginnings of insight. It appeared that I should have tried the ethernet switch and the factory defaults, right away, as alternatives to my custom configuration of the router. Experiencing success with one or both of those alternative approaches would have clarified matters.

But that wouldn't be networking -- because, now that I had unplugged and replugged the switch a few times, it was no longer doing the job on either computer. Everything was connected to it, as before, and the modem's lights looked right, but neither computer was able to connect. With the switch still connected, I tried rebooting the Win7 computer. It was no use. The Win7 machine was still not able to see the world, and the Ubuntu computer was pretending to connect. I powered down the switch and tried a direct connection from the modem to the Ubuntu computer. Still crawling. I powered down the modem for a minute. That did it: the Ubuntu machine was now going online without a sweat. I tried the switch again. That worked on both machines now. So apparently the switch did get confused and need some time off.

The conclusion seemed to be that, if I needed a router, I needed to try a new one, and otherwise I should just use the switch and power it down for a while if it failed to work.

Both computers were now going online successfully. What did the Win7 troubleshooters have to say about this? The Internet Connection troubleshooter said that it "couldn't identify the problem." This was apparently tactful speech: it seemed to mean that it couldn't identify *a* problem, but didn't want to tell the user that s/he was imagining things. The Incoming Connections troubleshooter said this:

Troubleshooting was unable to automatically fix all of the issues found. You can find more details below.

Problems Found

Windows requires more information to diagnose the problem.

Here, too, there seemed to be a bit of a bullshit factor. I had been taking these troubleshooters as though they meant exactly what they said -- that, in the latter case, there was a problem, though it was difficult to diagnose -- but now it began to seem that they might say this when there wasn't necessarily a problem. Pointing me to an online source of the "more information" that the program needed was a funny gesture when, according to the troubleshooter itself, I might not be able to go online. It seemed pretty lame, worthy of Windows 95. After all, this was Microsoft's software reporting on Microsoft's software.

What remained, it seemed, was to choose between the switch and a new router. That was a question for another post.

Ray Woodcock's Latest

Pages

Saturday, January 22, 2011

Windows 7: RAID or Mirror Across Computers?

Synchronizing Two Computers: Detailed Review of GoodSync

Monday, January 17, 2011

Windows 7, Vista, and XP: Networking Four Computers

Monday, January 10, 2011

Linksys WRT54GL Router: Brick Testing & Debricking

Wednesday, January 5, 2011

Windows 7 Fails to Detect Other Computer on Network

Support This Blog

Total Pageviews

Archives

Ray Woodcock's Latest

Pages

Saturday, January 22, 2011

Windows 7: RAID or Mirror Across Computers?

Synchronizing Two Computers: Detailed Review of GoodSync

Monday, January 17, 2011

Windows 7, Vista, and XP: Networking Four Computers

Monday, January 10, 2011

Linksys WRT54GL Router: Brick Testing & Debricking

Wednesday, January 5, 2011

Windows 7 Fails to Detect Other Computer on Network

Support This Blog

RSS Feed - Subscribe to My

Total Pageviews

Archives