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.

Synology NAS: Mapping the Network Drive

I had newly installed Ubuntu 10.10 and was trying to communicate with my Synology DS109 network-attached storage (NAS) unit.  I had previously resolved some problems with this unit, but some had remained unresolved; and now, in any case, I was starting over.

I had downloaded and installed DiskStation Manager (DSM) 3.0, the Synology Assistant, and the User's Guide.  DSM was a web-based program, apparently running on the DS109, that I accessed by simply typing the DS109's address (e.g., 192.168.2.1) into the Firefox address bar.  I was able to connect to the DS109 by typing the username and password that it needed (i.e., not my Ubuntu username and password).

As outlined in a previous post, I had also created a mount point ("sudo mkdir /media/SYNDATA") for the DS109's SYNDATA partition.  The fstab (i.e., "sudo gedit /etc/fstab") contained a line that had worked previously to let me contact that partition.  The line I was using was this:

//192.168.2.1/SYNDATA  /media/SYNDATA  cifs  user,uid=ray,gid=users,rw,suid,credentials=/etc/cifspwd,iocharset=utf8  0  0

where "ray" was my Ubuntu user ID, not my DS109 user ID.  The DS109 user ID was contained in the /etc/cifspwd file; and now, as I looked at this, I realized that reinstalling Ubuntu from scratch had surely wiped out that file.  So I recreated it ("sudo gedit /etc/cifspwd"), using my DS109 user ID and password, in this form:

username=[DS109 username]
password=[DS109 password]

and that's all that file contained.  Example:  if my DS109 username had been Joe, the first line in this two-line file would have been "username=Joe," and the second line would have been "password=JoesPassword" (wahtever that user's actual password was).  Then I typed these commands

sudo chmod 0600 /etc/cifspwd
sudo mount -a

These were the basic steps recommended in a relevant page in Synology's wiki.  The problem -- or at least *a* problem -- as I eventually figured out (or re-figured; Synology's tech support may have originally suggested it), was that the "credentials" part of the fstab line was not working.  If I replaced "credentials=/etc/cifspwd" with "username=Joe,password=JoesPassword" (and then saved fstab), then the "sudo mount -a" command worked:  SYNDATA appeared in Nautilus like any other partition.  So what would happen if I put exactly that -- username=Joe,password=JoesPassword -- on the same line in /etc/cifspwd, instead of putting them on two separate lines?  No dice.  The cifspwd file was a dud.  I left the username and password information in the fstab, and deleted the cifspwd file ("sudo rm cifspwd").

So the short answer I arrived at, here, was that the Synology wiki was wrong, at least for my purposes.  I needed to take all the other steps -- creating a mount point, etc. -- but instead of creating the cifspwd file, I just needed to enter a line in /etc/fstab of this form:

//192.168.2.1/SYNDATA  /media/SYNDATA  cifs  user,uid=[Ubuntu username],gid=users,rw,suid,username=[Synology username],password=[Synology password],iocharset=utf8  0  0

and possibly the "iocharset" part was optional.

VMware Workstation, Ubuntu Host, Windows XP Guest: Automated Way to Map Network Drives

I was using Windows XP virtual machines (VMs) in VMware Workstation 7 on Ubuntu Linux.  I wanted to automate the process of mapping network drives.  I typically used the Map Network Drive technique in Windows Explorer for this purpose.  It appeared possible to automate this with a registry edit, but apparently a  more typical and robust approach was to use the "net use" command.

The net use command could be entered from the command line.  I was more interested in saving it in a batch file that I could apply to multiple network drives and could re-run anytime without having to remember or research the proper syntax.  Microsoft seemed to say that, for my purposes, the command to map a network drive would look something like this:

net use d: "\\vmware-host\Shared Folders\DATA" /persistent:yes

where DATA was the name that I had given to the drive in Ubuntu.  This resulted in an entry in Windows Explorer that read, "Data on 'vmware-host\Shared Folders' (D:)."  I was not able, at this point, to automate the process of right-clicking and renaming that to be simply "DATA."

I combined several of those commands in a batch file.  A batch file was just a file created in Notepad, with one command on each line.  I also included a comment, in case I wanted to write an "undo" batch file.  The line just shown, made permanent and accompanied by that comment, looked like this:

net use d: "\\vmware-host\Shared Folders\DATA" /persistent:yes

; to disconnect, use this (I think):  net use d: "\\vmware-host\Shared Folders\DATA" /delete

I saved that batch file in the folder containing my various WinXP installation materials.  So then, for future installations, all I had to do was to double-click on that batch file in Windows Explorer, or start it from the command line or from another batch file, and my drive mapping would proceed automatically.