Tuesday, November 30, 2010

Selections from the Guggenheim YouTubePlay Shortlist (2010)

The contents of this post have been merged into a new Best Videos Ever post.

Sunday, November 14, 2010

Microsoft Word 2003: "Saving the Autorecovery File is Postponed"

I was using Microsoft Word 2003 in Windows XP.  In Tools > Options > Save, I had checked the box next to "Save AutoRecover info" and had set it to save every 1 minute.  I got a dialog that said, "Saving the AutoRecovery file is postponed for '[filename].'"  I clicked OK on that.  A minute later, it was back.  I clicked OK on it again.  I was able to use File > Save to save the document.  The dialog kept coming back.

I did a search for that message.  The first thread advised me to uncheck the "Save AutoRecover info" box, exit Word, search for all files beginning with ~$ or ending with .tmp, and delete them.  In Windows XP's classic mode, I went into Start > Search > For Files or Folders and searched on the Windows XP program partition (i.e., drive C, where Word 2003 was installed, as distinct from the separate partition where I stored my data) for ~$*.* .  I selected all of the files found.  I held down the Shift key and pressed the Delete key.  I re-ran the search and Shift-Del until there were no ~$*.* files left.  I did the same search and deletion process for *.tmp.  I confirmed file deletion even when I got a message indicating that one of the files being deleted was a system file.  There was one file I was not able to delete because it was "being used by another person or program."  I restarted Word and turned AutoRecover back on.  A minute later, the "AutoRecovery is postponed" message was back.  So that fix had not worked for me.

I had had this problem on a previous installation, so I did not try the advice of uninstalling and reinstalling Word.  The same thread advised me that perhaps Adobe Acrobat Pro 9.0 was the problem.  I closed Word and went into Acrobat > Help > Check for Updates.  It said the updater was already running, so I looked at the system tray (bottom right corner of the screen), right-clicked on the Adobe icon, and told it to install the update.  When that was done, I didn't restart Acrobat, lest it be the problem; I just closed it.  I restarted Word.  A minute later, the "AutoRecovery is postponed" message was back.

Another possibility suggested by that thread was that Word could be thrown off-balance by a change of drive letters or removing a hard drive.  I did not remember if I had changed anything of that nature since installing Word, and thus did not know how to go about fixing it if this was the problem.  In other WinXP problems related to drive letter errors, I had sometimes plugged in a USB drive and, using Start > Run > drivemgmt.msc, had relettered the USB drive to replace the offending or missing drive letter, and then rebooted, and that had solved the problem.  Possibly I could have resolved the problem in this case by working my way through the alphabet of drive letter possibilities until the problem went away.

I noticed another possibility mentioned in that same thread.  I had used Control Panel > System > Advanced tab > Performance Settings > Advanced tab > Virtual memory > Change to put my paging file on a partition other than drive C.  I had done this in the impression that this would make WinXP run faster and would also spare me from having to include several gigabytes' worth of paging file in my backups of drive C.  I decided to leave the paging file on that other partition, but I changed it from a fixed size to the "System managed size" option.  That required a reboot.  After the reboot, the problem was still there, so I tried putting the paging file back on C as system-managed, and rebooted again.  That didn't fix it either; the "AutoRecovery is postponed" message was back again.

I wondered if I had erred in deleting the *.tmp and ~$*.* files only from drive C.  My AutoRecover location was on a different partition.  I killed Word and, this time, just in case, hit Ctrl-Alt-Del and made sure that no Word processes were running. I re-ran the search, this time including that other partition.  But there were none of those kinds of files on that partition.  I ran the searches again, this time searching My Computer entirely.

It occurred to me, about this time, that the problem might be that I was putting my AutoRecover files on a drive other than C.  It wasn't a network drive -- but then, actually, it was:  I was doing this within a VMware virtual machine (VM), and VMware Workstation treated even a local hard drive as a network drive.  This, I thought, would explain why I was getting all those ~*.* files in the folder where I was saving my Word documents:  the "network" location was not being accepted.  I went into Word > Tools > Options > File Locations and changed the location to a folder on drive C, and then restarted Word.  That seemed to do it.  Ten minutes later, the error message had not returned.

Saturday, November 13, 2010

The Meaning and Origin of the "Woodcock" Surname

This post has been moved to another blog.

Friday, November 12, 2010

VMware Workstation 7.1 in Ubuntu 10.10 Host: VMCI Sockets Problem

I had installed VMware Workstation 7.1.2 on an Ubuntu 10.10 host.  Windows XP was not performing very well in it.  I wondered if the problem was that, when I started VMware Workstation 7.1.2, it said this:

Before you can run VMware, several modules must be compiled and loaded into the running kernel.
It gave me that same message every time I started Workstation.  When I went ahead and clicked on Install, it showed me the list of things that it was doing.  Last on the list was "VMCI Sockets."  Every time, it would show green checkmarks for all the other items, but for that item I would get a red exclamation mark.  If I started Workstation by using the "sudo vmware" command, Terminal would show me a list of error messages just before starting Workstation.  A number of those messages said this:
error:  'struct sock' has no member named 'sk_sleep'
Terminal also said that all of the other "Starting VMware services" processes went off OK, but "VM communication interface socket family" failed.

A search led to the suggestion to uninstall and reinstall Workstation, but one user there reported that that didn't help, though that appeared to be because s/he was using Xen Kernel.  Another webpage offered a patch to fix it.  I downloaded the patch, navigated to my download folder (using "cd" to change directories and having set the download folder in Firefox, Edit > Preferences > General tab), and typed these commands, as suggested:
tar -xzvf [patchname]

cd vmware-7.1-ubuntu10.10-patch
sudo sh ./apply_patch.sh
I have written "[patchname]" here because the filename of the download had changed since the original webpage was written.  The first command created a folder named "vmware-7.1-ubuntu10.10-patch" and copied files into it.  The second command put me into that folder.  The third command ran the patch.  When I ran the patch in the form suggested on the webpage, I got "Permission denied."  I revised the third command to the form shown above, and that ran successfully.  When I typed "sudo vmware" now, I got a green checkmark at all items, including VMCI Sockets.  So it worked.