Windows 7: Eliminating "This Folder Is Shared With Other People" Message

I had installed Windows 7.  Now, when I would try to move or delete some folders, I would get this message:

This folder is shared with other people.

If you move this folder, it will no longer be shared.

That message was correct:  I had, in fact, shared the parent folder (and all of its subfolders, including this one) with my other computer.  And I wanted existing and newly created subfolders to continue to be shared.  I just didn't want to receive this warning.

I tried the approach of going into Control Panel > HomeGroup > Leave the homegroup, because someone advised that this was the solution.  It wasn't.  I tried a search.  This led to a thread with some heartwarming rants about what a dumbass feature this was.  That thread also contained the suggestion that, at least for purposes of deleting (as distinct from moving) folders, a workaround was to cut and paste files and folders into Recycle Bin, rather than trying to delete them directly.  There was also a command line alternative that supposedly worked for wiping out lots of subfolders:

for /D %d in (*) do rmdir /S /Q "%d"

My guess was that the command line would also work for moving, in a pinch:  type MOVE /? for guidance.  But I didn't want a command-line solution.  The thread also offered a couple of other complicated workarounds with potential side effects.  Before going that route, I tried the suggestion to take ownership of the folder in question.  I had already added a Take Ownership context menu (i.e., right-click) option in Windows Explorer, so I used that now.  I used it at the level of the entire partition.  That didn't solve the problem.  I tried it again on the top-level folder.  That didn't do it either.  I verified that I had already given Full Control to Everyone in the Sharing context menu option, so that wasn't the solution either.

Another thread contained messages repeating the view that, as a deliberate feature of Windows, this couldn't be changed.  I took a look in TweakNow PowerPack 2012, in case they had a fix.  I hadn't really used TweakNow previously, but now I saw it wasn't really a tweaker in the sense that Ultimate Windows Tweaker (UWT) was.  So I ran UWT instead.  But no, UWT didn't seem to have a solution either.  So far, the only solution I had seen was that some people had repartitioned their drive and reinstalled Windows from scratch.  But that was a pretty draconian solution, and it didn't seem to guarantee against a recurrence of the problem.

Back in Windows Explorer, I right-clicked on the drive being shared and selected Properties > Security tab > Edit > Add > Everyone > Check Names > OK > Allow Full Control > OK.  That took a while, as it went through the drive, with a message that said, "Setting security information" various files and folders.  This was obviously not a very secure solution.  Nor was it logically related to sharing.  It was just a guess.

In another thread, someone said that they noticed this behavior began when they installed RC-1 (i.e., Windows 7, First Release Candidate).  As noted above, people had been saying it was a built-in Windows feature.  But there was at least the possibility that some program had triggered it.  In that spirit, someone else in that same thread offered the belief that it might be related to Windows Mail.  That was a possibility.  I had installed Windows Live Mail.  I didn't like it much -- it was very slow to start.  But I had already uninstalled it.  There didn't seem to be much more I could do on that front.  I tried running Glary Registry Cleaner, just in case that would make a difference.  It identified a lot of problems, but did not fix this particular one.  In another thread, someone suggested that the culprit might be the network sharing service in Media Player 11.

I saw recurrent references to the C:\Users\[username]\Appdata\Local\Temp\WPDNSE folder.  For username Ray, mine had nothing in it.  Evidently they came to that folder because its name was appearing in an error message.  I wasn't getting that.  The general idea seemed to be that one user might somehow be linked to another user at that folder.  That was interesting.  I looked into the possibility that this "shared folder" problem might be due to the existence of an unnecessary user account.  As described in another post, I pruned out some extraneous user accounts.  But that did not resolve this problem.

Over time, the problem appeared less frequently.  It seemed that there might have been an ownership or sharing event, occurring at one time, that became less relevant as my folders went through various processes of being renamed, moved, reshared, and so forth.  One post gave me the idea that the problem might be in Windows Explorer > select a folder > right-click > Properties > Sharing tab > Advanced Sharing > Permissions.  At this moment, the only group or user listed there was Everyone.  It seemed that, previously, there might have been additional entries there, for Ray, Administrators, and/or System.  The post made me think that, even though all roads seemed like they should lead to Mecca, the mere presence of multiple people here would confuse Windows.  Maybe the original warning that "This folder is shared with other people" was Windows' way of telling me that it was going to remove the others and leave only Everyone on the list.  I didn't test this; this was just an idea from that post.  At the time when I decided to close this post, it's not so much that the problem had disappeared as that it had become more rare.

Windows 7: "Access Denied" on the Command Line When Using FIND

I tried to run a FIND command in the CMD (sometimes called the DOS) box in Windows 7.  I got an error message:

Access Denied - D:\FOLDER\SUB FOLDER

This was bizarre.  I had been using the command line in this Win7 installation for months.  Well, something had apparently changed.  I got this message regardless of whether I used my pre-installed "Open Command Window Here" right-click option in Windows Explorer or the Administrator Command Box option I had created in the Start menu.

A search led me through various possible solutions.  I tried especially to tweak the permissions for the entire partition and for the individual folder via right-click > Properties > Security tab > Advanced > Owner tab > Edit > select Administrators and check "Replace owner on subcontainers and objects," and to play with other tabs and settings in that vicinity.

One option I hadn't seen previously was to open the Local Group Policy Editor (Start > Run > gpedit.msc) and go into Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > right-click on "User Account Control:  Behavior of the elevation prompt for administrators in Admin Approval Mode" > Properties > Elevate Without Prompting.  But I already had that selected.

That writeup raised the question, though:  had I not completely disabled User Account Control (UAC)?  As advised, I went into Start > Run > Regedit and navigated to HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System.  There, I right-clicked on EnableLUA and verified that the value was zero.  Nonetheless, I exported the tweak, extracted the relevant lines from the REG file, and added them to my Win7RegEdit.reg file for future installations, just to be sure.

When I was in Permissions (via Windows Explorer folder right-click > Properties > Security tab > Edit), I noticed that the permissions checkboxes were checked but greyed out.  I couldn't change them.  Was I somehow not in the right account?  A search led to a proffered batch file (Permissions.zip) that read as follows:

@echo off
title File/Folder Permissions
echo.
echo.             BY KAOS - Windows 7 Forums
echo.
echo.
set /p a=Enter Path Of File/Folder:
echo.
set /p b=User Name:
echo Type "deny" = remove access OR type "grant" = allow full access
set /p c=Permission Type:
echo.
echo.
echo.
if %c%==deny goto lock
if %c%==grant goto unlock
if %a%==menu goto start2
if %b%==menu goto start2
if %c%==menu goto start2
:lock
cacls %a% /e /d %b%
cls
exit
:unlock
cacls %a% /e /g %b%:f
cls

The gist of this batch file seemed to be that I could try a CACLS command of this form:  cacls [folder path] /e /g [username]:f, where /e meant "edit," /g specified the user, and :f gave full control.  So, in my case, what username would I use?  Control Panel > User Accounts said that I had set up my system so that the only options were Ray (Administrator) and Guest (turned off).  Maybe this was the problem:  I had been thinking in terms of the Administrator account rather than the Ray account.  So, OK, I tried typing this on the command line, to grant full control to the whole drive:

cacls D:\ /e /g Ray:f

In response to that command, I got a short message:  "processed dir: D:\.  Did that mean champagne?  I retried the command that had given me the "Access Denied" error.  No, still denied.  Alright, how about same command, different user:  Administrator.  Same output.  Still denied.  Baffling!

I ran across a post that said something about turning off simple file sharing and permissions, and then permissions.  It raised a question:  was there a way to reset permissions to the default, and start over?  For the drive (i.e., right-clicking on D: in Windows Explorer), I went into Share with > Advanced sharing > Sharing tab > Advanced Sharing.  I unclicked Share This Folder > Apply.  I got a note indicating that I had some files currently opened, and they would be closed.  I clicked Yes > OK > Close.  This, in itself, didn't have any effect on another try of the FIND command; still denied. 

I had recently gotten an indication that the Recycle Bin on drive D was corrupted.  I had said go ahead and empty it.  That message had recurred.  I had also been getting bothersome messages when I tried to move or delete folders, telling me that these folders were shared and confirming that I really wanted to do what I had said I wanted to do.  It seemed that these problems might be related.  But how, and what could I do about it?

I found a Windows XP article from 2002 that said, "If you don't have a thorough understanding of the various permissions and their relationships, it can be nearly impossible to sort out a permission problem and find a solution."  So I could see how Windows 7 was a direct descendant from Windows XP:  both could make it impossible to get any work done.  The article said that there was a difference between sharing permissions and NTFS permissions, and that the more restrictive one wins.  So if I wanted to grant full control to everyone for everything, I had to do that in two different right-click > Properties tabs:  the Sharing tab and also the Security tab.  But it really looked like I had done that, over and over again.

Ah, but now I saw a new problem.  In the Security tab, I saw that I had a little red circle with an X in it, next to the Administrator group.  There was no right-click option to explain it.  I guessed that the problem was that I had entered the wrong CACLS command, regarding Administrator rather than Administrators (plural).  So that was interesting.  I clicked on Edit, selected Administrator, and clicked Remove.  Then I re-ran that CACLS command with a reference to Administrators, this time, instead of Administrator.  But still no joy on my FIND command:  Access denied.

So anyway, as I was saying, it did seem that I had given full control to almost everyone listed in the Security tab.  I mean, literally, Everyone:  I had an entry for them, and they had full control, and so did SYSTEM, Ray, and Administrators.  But not Authenticated Users, and not plain old Users.  Who the hell were all these people, anyway, and why did we all need to have so many kinds of access to my computer so that I could get work done?  (Sigh.)  Wiser minds knew; I did not.  Anyway, I went ahead and gave full control to my whole world to everyone and his brother, Users and all.  And still the godforsaken command did not run.

And, by the way, at this point I searched in vain for those greyed-out permissions boxes I had seen earlier.  Evidently I had altered something significant, in all this screwing around.  Not so significant as to actually let me get any work done, but significant certainly in the sense that I could no longer detect greyness when I searched therefor.  Not in the Security, nor back in the Sharing tab.  Speaking of which, I now saw that my reestablished share of drive D now had permissions only for Everyone.  Did Everyone include me and all the other Administrators and Users and Authenticated Users of my home system (I was living alone), or did I need to add the whole gang back to my computer?  Not sure.

It occurred to me that I did have a solution.  It was called System Restore.  But, alas, the mere fact of telling Windows to keep system restores, accompanied by weekly checking to make sure that the task was really running as scheduled, did not necessarily mean that I would actually have recourse to any system restore points, other than the one created that very morning.  Apparently Windows was not content with the 10GB of disk space I had set aside for this purpose.  Fortuitously, I did have an Acronis drive image from a week or so earlier, and so, without further ado, I wiped the drive and restored that.  Did there exist any further difficulty?  Yes, there did.  My Acronis backup was too recent.  Apparently this problem had lurked for days and/or was not only, or primarily, a matter of drive C (stored in Acronis) as distinct from drive D (not backed up in Acronis).

I tried a different command that, I knew, I had run within recent days:  DIR.  It ran.  Now, why would DIR run and FIND not run?  FIND took a look inside files; were my permissions of some type not reaching into the files?  I right-clicked on the files in question.  They didn't have sharing or security options collectively; I had to click them one at a time to get a Security tab.  It said everyone had full control.  The Advanced > Owner tab option said the owner of at least one file was Administrators.  Anyway, the CACLS command was supposed to take care of user accouint issues.

I tried the same FIND command on another computer of virtually identical configuration.  It, too, provided a FIND error.  A search led to a brilliant insight:  my command was wrong.  I was trying to use FIND on a directory, when it only works on files.  I had to make one change:  I had to add a star (asterisk) to the end of my search.  The FIND command worked without error when I did it this way:

find /i /c "X-Message-Delivery:" "D:\Folder\Sub Folder\*"

Solution:  operator error.  Case closed.

Windows 7 Cannot Find Acrobat.exe

I was working in Windows 7.  I had installed Adobe Acrobat 9 Pro.  In Windows Explorer, I selected two PDFs, right-clicked, and chose the option to "Combine supported files in Acrobat."  I got an error message:

Windows cannot find 'Acrobat.exe'.  Make sure you typed the name correctly, and then try again.

I clicked OK to get rid of the dialog.  I noticed that I got this error only if Acrobat was not currently running.  If I had Acrobat open, I would not get the error; instead, I would get the expected Combine Supported Files dialog, and I would be able to go ahead and combine the PDFs.

Of course, I didn't want to have to open Acrobat in order to combine files, although doing so would give me the alternative option of combining the files from within Acrobat, instead of starting from Windows Explorer.  In Acrobat 9, the menu picks for that approach were File > Create PDF > Merge Files into a Single PDF.  And that approach did have the advantage, in at least some Acrobat installations, of not crashing Acrobat (or worse) when I would be trying to merge a large number of PDFs.

I wanted to recover ordinary functionality, so that I could right-click a selected group of PDFs in Windows Explorer and merge them using the "Combine supported files" option.  A search led to a thread that suggested adjusting Windows so that it would open PDFs in a slightly different way.  The instructions there were for Windows XP and Acrobat 6.0.  They suggested adding a certain command-line switch (a/k/a option, parameter, or flag) when Acrobat (or Adobe Reader) would open files.  A search led to an Adobe page that listed six switches:  /n (to start a new instance of Acrobat), /s (to suppress the splash screen), /o (to suppress the open-file dialog box), /h (to start Acrobat minimized), /p (to start Acrobat and open the Print dialog), and /t (to start Acrobat and print a specified file).  (One source seemed to indicate that there might be quite a few other switches as well, controlling such things as the document page that would open and the zoom factor.)

The suggestion that I had found was to add the /n switch to the command that opened Acrobat.  That suggestion seemed to have something in common with the discovery (above) that the Combine right-click option would work when Acrobat was already open.   The problem was that Windows 7 no longer made it possible for users to add switches as they could in Windows XP.  The Tools > Folder Options > File Types tab was no longer available in Windows Explorer.  It would have been possible to run Acrobat by adding the /n switch to the properties of a shortcut, but that didn't seem relevant for this Combine Supported Files project.  A better possibility was to use the Run with Arguments option in FileMenu Tools, but it would require a couple of steps every time, assuming I could get it to work.

I just wanted to restore, in Windows 7, the old ability to specify command-line switches for programs like Acrobat.  Some utilities seemed to offer that possibility.  A closer look at Types suggested that it wasn't right for the job, but it seemed that NirSoft's FileTypesMan might be.  FileTypesMan turned out to be a portable:  I just double-clicked on its .exe and it ran without any need for installation.  I did a Ctrl-F to search repeatedly for PDF file types.  I right-clicked on the line for the PDF extension and got a good number of choices.  A somewhat similar list of options dropped down when I clicked on the menu bar's Edit pick.  It looked like I would need to use the "Open file type in RegEdit" option.  That opened up the Windows 7 registry editor and took me directly to what looked like an appropriate place for Acrobat.

But now what?  I wasn't sure what to do there, so I ran a search.  It led to a few hints, but nothing clear.  I decided to search the registry, to see if I could find the location of the "Combine supported files in Acrobat" option.  A Ctrl-F for that phrase turned up nothing.  Nirsoft's ShellMenuView didn't indicate where that option came from either.

When I double-clicked on the .pdf file type in PC Magazine's old ContextEdit utility, it took me to an Adobe Acrobat Document entry.  On closer examination, I saw that this was actually the second of two such entries.  The first one seemed to indicate that the default program for such documents was Adobe Reader, not Acrobat.  Was that why Acrobat was acting funny -- had Reader screwed up my right-click context menu action?  I wasn't sure when Reader had joined the party.  I hadn't consciously intended to install it.  But now that I thought of it, I guessed that this was why the icons for my PDFs had changed slightly.

So, OK, in Windows Explorer, I right-clicked on a random PDF and went into Open With > Choose Default Program.  Reader was highlighted.  I highlighted Acrobat instead, made sure the checkbox at the bottom was checked ("Always use the selected program to open this kind of file"), and exited.  I selected two PDFs and tried the right-click Combine option.  No joy.  I wasn't sure whether a reboot would make a difference, but I rebooted just in case and tried again.  Still no go.  But, bizarrely, Reader was still highlighted in the Open With dialog.  I didn't need Adobe Reader, so I went into Control Panel > Programs and Features and uninstalled it.  I did the Open With thing again, and now Reader was gone.  I highlighted Acrobat once more in the Open With dialog -- and, yes, back in Windows Explorer, my PDF file icons returned to their old familiar Acrobat form.

I tried Combine Supported Files again, but I still got the error.  I started to go into Acrobat, with the intention of running its Help > Repair Acrobat Installation option.  But for some reason, the Windows Installer started up before Acrobat ran.  I guessed that the departure of Reader had left a gap, and now Acrobat was going to reconfigure itself to take up the slack.  After it was done, it called for another reboot.  I tried Combine Supported Files with two PDFs, but still got the error.  Apparently Reader wasn't the cause of the problem, or at least Reader's removal wasn't the cure.

Another change that I had noticed recently:  when Acrobat was updating, I commonly got errors referring to Error 1310, involving C:\Config.msi.  That had not happened previously.  I did not know whether this was related to Reader, or to the Combine Supported Files error.

Anyway, I went back into ContextEdit, to that second Adobe Acrobat Document entry.  I double-clicked on its Open option.  This opened a command line edit dialog.  The command line was the same as the one that people in that thread (above) had been revising.  Following their advice, I changed the command line so that it looked like this:

"C:\Program Files (x86)\Adobe\Acrobat 9.0\Acrobat\Acrobat.exe" /n "%1"

This just involved inserting that /n before the "%1" variable.  In the dialog's Menu Text box, I added "Open in New Acrobat Session," and then exited.  Sadly, no such option appeared in my right-click menu.  I rebooted, but that made no difference.  It seemed that ContextEdit must still be thinking in terms of the Windows 98 registry.  I went back in and removed that /n switch from its dialog box.

In case Acrobat hadn't fully repaired itself, I now went into its Help menu and ran a repair.  After another reboot, I tried Combine Supported Files again.  I still got the error.  I uninstalled Acrobat (via Control Panel > Programs and Features), rebooted, and reinstalled it.  (Note that Acrobat may have to be deactivated via Acrobat's Help menu before uninstallation, so as to avoid a hassle when activating after reinstallation.)  When it was reinstalled, there was no Combine Supported Files option.  I rebooted.  Still no such option.  It developed that I had made an error during the installation:  it was OK if the custom option to install the Create Adobe PDF was installed fully (white) or without some or all of its subfeatures (grey), but it could not be completely noninstalled (red X).  The red X would mean that the Combine option would not be available.  It occurrred to me that another possible way to fix the problem, short of completely uninstalling and reinstalling Acrobat, would have been to turn off that particular Create Adobe PDF option, reboot, and then turn it back on.

Uninstalling and reinstalling turned out to be the solution, at least with Reader out of the picture and with the other tinkering described above.  With the Create Adobe PDF option installed, the Combine option was there, without requiring a reboot.  And when I used it, it worked without an error.

Testing to Verify That Photo Files Are Good

I had a bunch of JPGs in different folders.  I wanted to convert them to PDFs.  In the process of doing this, I found a way to verify that the JPGs were still of good quality.  This post describes that method.I wanted to move the files in this case, but it would also work to just make copies of them and run through these steps on the copies.

I began by opening a DOS box, also known as a command window.  I was using Windows 7, but substantially the same steps would work in other versions of Windows.  The easiest way to open a DOS box was to have a context menu (i.e., right-click) option to open a command window in Windows Explorer.  I had added that option using Ultimate Windows Tweaker (UWT).  The option in question was in the Additional Tweaks section of UWT.  This option added an "Open Command Window Here" context menu (i.e., right-click) option in Windows Explorer.  If I hadn't planned on using command windows frequently, I could also have just gone to Windows 7's Start button > Run > cmd.

First, I assembled a list of files to be copied or moved.  The command I typed for this purpose was this:

     DIR "D:\Source Place\*.jpg" /a-d /s /b > D:\Dirlist.txt

with quotation marks, spaces, and everything else exactly as shown.  (If a command is hard to read here, it can be made larger with Ctrl-+ (i.e., hold down the Ctrl key and hit the + key on the numeric keypad).  You can also copy and paste it into a word processor or Notepad to make it more legible.)  I would have needed to run this command again if I'd been searching for JPEGs as distinct from JPGs.  This command gave me a list of JPGs that existed on my hard drive in a folder on drive D called Source Place, or in any subdirectories under that folder.  The list was contained in a file called Dirlist.txt, located at the root of drive D.  To see what command-line options (e.g., /a-d) were available, I could type, in a DOS box, the command with a /? after it.  For example, I could get the parameters for using the DIR command by typing "DIR /?" (without quotation marks).

Once I had my list of the JPGs I wanted to test, I could move or copy them to another folder where I would be doing the testing.  I created a folder called D:\TestJPGs for this purpose.  To move the JPGs there, I opened the Dirlist.txt file in Microsoft Word, though any editor capable of recognizing the ends of lines of text would be able to do the job.  (Using Word did require me to do the final editing in Notepad:  I had Word set to insert smart quotation marks, and those would not run as commands, so the last step before running a batch command file created in Word was to copy it into Notepad and replace the Word-style quotation marks with plain-text Notepad-style quotation marks.)  Using global search and replace in Word, I changed each line in Dirlist.txt to the following form:

     MOVE "D:\Source Place\Subfolder A\photo.jpg" -y D:\TestJPGs

In other words, Dirlist.txt provided the list of files that could be converted into a list of commands.  Quotation marks were not necessary around that destination name (i.e., D:\TestJPGs) because there were no spaces in that file or path name.  Doing global changes to insert things at the beginning and ends of lines was easier with the knowledge that ^p was a common line-ending character in Word.  It seemed necessary to use the Dirlist.txt step because the MOVE command did not offer a /s option.  That is, I would have to explicitly identify JPG file locations and command them to be moved.  Note that somewhat different options were available for the COPY command as distinct from the MOVE command.

Once I had all the JPGs in a single place, I could run a test on them.  The test consisted of simply converting each JPG into a PDF file using the free Irfanview program.  (If all the files to be tested were already in one place, of course, the foregoing MOVE or COPY options would not be necessary.)  In Irfanview 4.28, the command to be used was File > Batch Conversion/Rename.  There, the necessary steps were to select the files to be tested, click Add, designate an Output Directory, and then go to the Batch Conversion Settings area and indicate PDF output format, though probably other formats would work too -- taking care to click Options and adjust quality levels if you planned to keep the converted output files.

Then I clicked on the Start Batch button, there in Irfanview.  When the conversion process was done, Irfanview gave me a list of messages regarding files that had converted successfully to PDF, along with some that had not.  I sorted this list in Word and saved the ones that were in this format:

     Error! Can't load: E:\JPGs\filename.jpg

I verified that neither Irfanview nor Windows Photo Viewer could view those files.  My next step was to search for a JPG repair utility.  This search led eventually to JPEGsnoop, which (after the assorted misleading websites I encountered along the way) was a refreshingly genuine freeware program of repute.  I downloaded and tried it.  JPEGsnoop (also apparently good on AVIs and other filetypes) turned out to be able to detect bad JPGs, thus simplifying much of what I was trying to do in this post.  It wasn't perfect, though:  it got hung up on a photo that Irfanview was able to open with no problem.  It also created a separate .txt file per JPG, containing file information for each JPG it examined, which I didn't need right now, so I had to manually delete those.  Another program of this type, ImageVerifier, whose webpage seemed to present a programmer who was doing a lot of thinking and experimenting about how to verify and preserve files with the use of a database scheme.  After installing it, they told me that it would only evaluate 50 files unless I bought the paid version.  So at this point, I wasn't sure these were better than the IrfanView approach (especially since I did ultimately want PDFs to replace the JPGs with).

Returning to the question of how to repair JPGs, I did encounter the occasional webpage on how to manually edit JPGs to fix them, but this was not something I was going to get into at this time.  I didn't find any freeware for this purpose.  I did find some shareware, but it didn't seem to be very highly rated, specifically All Media Fixer and DDR Digital Picture Recovery.  Possibly PixRecovery was a superior alternative -- at a price of $149.  At this point, I had to conclude that the world was still waiting for a good, free, automated JPG repair program.

Windows 7: Item Not Found Error

Suddenly, when I was moving folders, I started getting a stupid message that the folder that I was moving was no longer where it used to be.  The message was specifically as follows:

Item Not Found
Could not find this item
This is no longer located in [source folder].  Verify the item's location and try again.

Trying again would finish the move.  I wanted to stop getting this message.  I ran a search and came up with a thread suggesting that the problem was with a Windows 7 update, KB980408.  That thread led me to a .reg file, which I downloaded and ran:

Windows Registry Editor Version 5.00

[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions\{2112AB0A-C86A-4ffe-A368-0DE96E47012E}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions\{2112AB0A-C86A-4ffe-A368-0DE96E47012E}\PropertyBag]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions\{491E922F-5643-4af4-A7EB-4E7A138D8174}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions\{491E922F-5643-4af4-A7EB-4E7A138D8174}\PropertyBag]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions\{7b0db17d-9cd2-4a93-9733-46cc89022e7c}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions\{7b0db17d-9cd2-4a93-9733-46cc89022e7c}\PropertyBag]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions\{A302545D-DEFF-464b-ABE8-61C8648D939B}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions\{A302545D-DEFF-464b-ABE8-61C8648D939B}\PropertyBag]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions\{A990AE9F-A03B-4e80-94BC-9912D7504104}]
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions\{A990AE9F-A03B-4e80-94BC-9912D7504104}\PropertyBag]

That seemed to take care of it.

Windows XP in VMware Workstation 7.1: Windows Explorer Keeps Refreshing

I was running Windows XP SP3 as a guest in a virtual machine (VM) in VMware Workstation 7.1.1 on an Ubuntu 10.04 (Lucid Lynx) host.  I had just installed a couple of freeware utilities when suddenly Windows Explorer began refreshing itself about every two seconds.  More specifically, it was refreshing the right-hand pane, showing files and folders, but not the left pane, showing the folder tree.

I thought at first it was a virus, but I was running antivirus software, and a scan with a different antivirus program turned up nothing.  Besides, I had just downloaded those programs from reputable sources (e.g., CNET) that supposedly certified them to be virus-free.

A search suggested this was a relatively common problem.  Several posts made me think it had to do with network drives, which in this case would mean the link between Windows and VMware.  I killed the VM, reverted to a previous snapshot, and started that, but the same thing was happening there as well.  I powered up a different VM in a different session of Workstation.  The problem was not occurring there.  I closed all sessions of Workstation and powered up the misbehaving VM in a new session of Workstation.  The problem recurred -- but then, after a minute or two, it stopped.  But then, after I used Windows Explorer some more, it resumed; but then it stopped again.

I downloaded the "Prevent Automatic Folder and Icon Refresh" registry edit from Kelly's Korner and ran that, and then rebooted Windows within the VM.  The problem was still there.  I took this to mean that *automatic* refresh was not the problem -- that, presumably, something was manually refreshing Explorer.

I tried displaying different drives' contents in Explorer, on the theory that maybe this was happening in connection with just one particular network drive.  That was not the case; it happened on all of them.

I wondered if a program installation was responsible for the problem.  But it was not clear to me how any of these would have been responsible for the fact that the flashing occurred within a snapshot that I had taken before installing them.

Then I came closer to what seemed like a possible answer.  I tried again to install the Microsoft Task Switch Powertoy.  I had tried before, and it had given me an error message, and the same thing happened again.  The error message was "Error 1606.  Could not access network location [gibberish]."  The gibberish was actually just a set of five squares with no characters in them.  It appeared that the installer was trying to access a network location whose name did not consist of valid characters.  Following advice, I checked the following registry keys for incorrect addresses:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

I did find several bad entries in the second of those five locations.  I corrected those and rebooted the VM.  I was now able to install the PowerToy.  Unfortunately, the flashing was still going on.  I went into VM > Settings > Options > Shared Folders and switched that to Disabled > Save.  The flashing stopped.  In Windows Explorer, I tried to go to another network drive, but got the message that it "is not accessible.  The network path was not found."  I went to drive C (not a network drive).  Its contents displayed OK.  No flashing.  I set Shared Folders back to Always Enabled.  No flashing on drive C.  Flashing on drive D.  I tried C again.  The folders there would refresh once, immediately after being selected, but then not again.  In Windows Explorer's menu, I went to Tools > Disconnect Network Drive and disconnected drive D.  Drive E was still flashing.  I went to Tools > Map Network Drive and mapped D again.  It was flashing.

A Microsoft Knowledgebase webpage said that a somewhat related problem (flickering in the left-hand pane of Windows Explorer) could be repaired at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer.  I had only a lowercase "policies" (not "Policies") key at that location.  Regedit would not let me create the uppercase version.  So I went into the lowercase "policies" key.  It did have an Explorer subkey.  I went in there and created a new key, NoRemoteRecursiveEvents, of REG_DWORD type, and gave it a value of 1.  I exited regedit and rebooted.  This step did not solve the problem.

I closed this VM and went back to the previous version, the one that did not flash.  I corrected the incorrect registry addresses (above) first.  Then I started reinstalling the programs that I had been installing when the problem began.  I went down the list and, what do you know, the flickering started when I installed FolderSize, and it stopped when I uninstalled it.  FolderSize calculates the size of folders, and apparently refreshes the screen while it does so.  After I uninstalled it, the problem went away.

Windows XP in VMware Workstation: Default Host Application Error

I was running a Windows XP SP3 guest in VMware Workstation 7.1 on an Ubuntu 10.04 (Lucid Lynx) host.  When I tried to open a PDF file in the VM, I got a Default Host Application error message:

Default Host Application
Make sure the virtual machine's configuration allows the guest to open host applications.

A search for that sentence turned up no hits.  A modified search turned up only a few.  One thread led me to right-click on the PDF and select Open With.  There, for the first time ever, I saw the VMware icon and "Default Host Application" at the top of the list, labeled as the Recommended Program.  I clicked OK, but this put me back to the Default Host Application error message.  I guessed that maybe the problem was that I had already told Ubuntu to use Adobe Reader for Ubuntu (or maybe some other program) to be the default application for PDF files.  I had meant that to apply only when I was in Ubuntu, not when I was in a WinXP VM.  I checked VM > Settings > Options tab > Guest Isolation, and it did not have the box checked to "Enable VM communication interface (VMCI)."  So that seemed to be prohibiting the host (Ubuntu) from using its own default program to open the PDF when I was in the guest (WinXP).

The VMware Workstation 7.1 User's Manual made me wonder whether I had slipped into Unity mode, but I checked Workstation's View menu pick and, no, the setting was Autofit Guest.  I tried Open With again, but this time I browsed to the program that I wanted to use to read PDFs.  At this point, that program was Sumatra PDF.  But after I clicked on the Sumatra PDF .exe file, I was back at the Open With, and it had not remembered what I had just done.  I did it again; same result.  I tried WordPad instead.  It rendered the PDF as what looked like an XML file.  I closed that, went back to right-click > Open With, and this time the VM Default Host Application and WordPad were the only two programs listed.  Still no luck with Sumatra.  Another post made me think this was actually intended behavior, under the concept of "application sharing."  I didn't pursue that at this point.

In Windows Explorer, I went to Tools > Folder Options > File Types, scrolled down to the PDF file type, clicked Change, navigated to Sumatra . . . but still the same result:  it didn't remember what I had selected.  Following a tip, I went to Start > Run > CMD and typed "assoc .pdf."  This told me that the PDF file type was associated with pdf_auto_file.  A corresponding search led to the suggestion to go back into the File Types list, down to PDF, and click on Restore to reset it to the Windows default program for PDFs.  Now it wasn't set to run with anything.  I clicked on Change and navigated to Sumatra again, but it still didn't remember it.

The Microsoft Support page didn't seem to address this situation.  Ramesh, however, did provide an OpenWithAdd utility that added Sumatra to the Open With list.  After that, double-clicking on the PDF file opened the Open With list, with Sumatra PDF highlighted.  I clicked on the "Always use the selected program to open this kind of file" box and then OK.  I killed Sumatra, double-clicked on the PDF again, and this time Sumatra opened right up.  Problem solved!  Another way of doing it, if I hadn't wanted to run the OpenWithAdd utility, was apparently to use this registry edit:

[HKEY_CLASSES_ROOT\.pdf]
@="AcroExch.Document"

When I went to that location in my registry, I saw that it was still set to pdf_auto_file, so I made that change.  I wasn't sure whether that would have eliminated the need for the OpenWithAdd utility.

Ubuntu 10.04 vs. Windows XP: Can't Delete a File

Many Windows users have encountered files that they cannot delete.  I had been able to handle most of those problems pretty easily.  The tools I used were Unlocker, to delete the problem file from within Windows conveniently, and Ubuntu Linux, when Unlocker failed.

I was able to switch to Ubuntu pretty quickly, if necessary.  I was using Ubuntu 10.04 on a dual-boot system.  I had installed VMware Workstation 7.1 in Ubuntu, and had created a virtual machine (VM) running Windows XP SP3 in Workstation.

But in this case, I wasn't having file deletion problems in Windows; I was having file deletion problems in Ubuntu.  Specifically, I was running into difficulties when trying to use an external USB hard drive.  For instance, when I tried to delete a file from the external hard drive, I first got this message:

Cannot move file to trash, do you want to delete immediately?

No problem there, to my knowledge; it was a 2.2GB .avi (i.e., video) file, so maybe it was too big for the trash.  So I clicked Delete.  This gave me "Error while deleting," and when I clicked on "Show more details," I got this:  "Error removing file:  Input/output error."  Similarly, when I tried to move some .avi files manually from the internal hard drive to the external USB drive, I got "Error while copying" and, in the details, "Error opening file [filename]:  Input/output error."

Through a relevant search, I came across a post that made me think I should try to approach this from the Windows side.  That seemed ironic at first, but then I reflected that the target drive was NTFS.  That is, it was formatted for use by Windows.  I wasn't having this problem with my Ubuntu ext3-formatted drives.

So I went into Windows and tried to do the same maneuvers I had just tried in Ubuntu:  connect to the USB drive; delete one file from the external (NTFS) USB drive; move files from an internal (ext3) drive to that external USB drive.  I didn't get too far.  Windows said the folder on the USB drive "is not accessible.  The file or directory is corrupted and unreadable."  Was that what "input/output error" in Ubuntu meant?

I ran Disk Management (Start > Run > diskmgmt.msc), right-clicked on the USB drive > Properties > Tools > Error-checking > click both boxes > Start.  I clicked on out of there and rebooted so that the error check would run.  But this did not repair the drive.  On a second try, I watched more closely.  The VM did reboot, but it did not run a disk check.  Apparently the problem was that the external USB drive did not become connected to the VM until after the operating system had already restarted, by which time it was too late for a disk check.  So I rebooted the VM again, this time with a WinXP installation CD in the CD/DVD drive, and ran CHKDSK /R from the Recovery Console.

CHKDSK ran for a while and then said, "The volume appears to contain one or more unrecoverable problems."  This particular external drive consisted of a hard drive in an external enclosure.  I took the drive out of the enclosure and put it directly in the computer.  This time, CHKDSK ran successfully.  I repeated CHKDSK until it reported no more errors, and then put the drive back in its enclosure.  Now I was able to delete the file.  Problem solved!

IrfanView Error: Windows Can't Play This File

I was using Windows XP SP3 as the guest operating system in a VMware Workstation 7 virtual machine (VM) on Ubuntu 10.04 (Lucid Lynx).  For some months, I had been using IrfanView to play various audio and sometimes video files in that VM.  Suddenly, with a number of files, I started getting this error message:

IrfanView
Error:  Windows can't play this file!
Windows error text:  The specified file cannot be played on the specified MCI device.  The file may be corrupt, not in the correct format, or no file handler available for this format.
You can try to install additional video/audio codecs from this site:
http://www.fourcc.org/indexcod.htm
or try the DirectShow option in 'Properties->Video'

At first I thought this was a problem with IrfanView.  I upgraded to the most current version of IrfanView and tried again.  The error was still there.  I tried playing the file in Windows Media Player (WMP).  I got this message:

The file you are attempting to play has an extension (.wav) that does not match the file format. Playing the file may result in unexpected behavior.
Do you want the Player to try to play this content?

I said Yes.  It took a few seconds, but then it was able to play the file.  So yes, IrfanView was not handling it as well as WMP, but both of them were telling me there was a problem with the file.  And then I knew what the problem was.  I had bulk-renamed a bunch of files, and had inadvertently named some *.wma files to be *.wav files instead.  I renamed this file to be filename.wma instead of filename.wav.  Now IrfanView was able to play it without a problem.

I was surprised to encounter this problem.  IrfanView had an "Ask to rename if incorrect extension" option, and I had enabled it.  That option had often asked me if I wanted to rename a file that had somehow acquired an incorrect extension.  Why not this time?  Apparently IrfanView was not able to detect the problem in this particular scenario.  I checked what codecs I had been installing.  I was not too sure what codecs were all about, and for some years I had been using K-Lite Codec Packs as a sort of all-purpose Band-Aid.  But as I checked on it, it appeared that I had just been reinstalling the same old copy of version 3.5.9 or possibly 4.7.0, whereas K-Lite was now up to version 6.0.4.  So I downloaded and installed the latest 32-bit K-Lite Mega Codec Pack.  It was a big honker -- 25MB -- but my understanding was that, if somebody sent me a file of a Mongolian shepherd beating on a bucket and recording it on a 1960-era IBM tape drive, this would be all I would need to enable Windows to play it in five-channel glory with four-part harmony.

Installing and Using IrfanView for Audio in Ubuntu 9.04

I have an Olympus VN-960PC digital voice recorder (DVR). It saves its recordings in compressed .wav format files. When I listen to those recordings, I usually use IrfanView to listen to them. I have been using IrfanView for years, and have found it to be markedly more useful and flexible than any other program for many image editing, audio listening, file viewing, and other multimedia tasks. It is really amazing freeware.

I use IrfanView for this particular task because I have not yet found another program that allows me to move from one recording to the next so quickly. I listen to the notes I have saved on the DVR; I highlight some of them, one by one, in Windows Explorer, and then I cut and paste the selected recordings to subfolders for further use. I have developed the habit of beginning many of my recordings with a single word (e.g., "Monday" or "shopping"), so I know right away which folder it goes into. Sorting a number of audio recordings this way is very fast.

IrfanView was a Windows-only program. I could not find anything in the Linux world that could replace it, for my purposes, so I looked for ways to run it in Ubuntu. One possibility, which I used for a long time, was to run it in a virtual machine in VMware Workstation (or perhaps I could have used a freeware virtualization program) on Ubuntu. I was engaged in a long-term effort to move away from dependence on Windows, though, and sometimes virtual machines could be somewhat clunky.

Finally, at one point I reached a situation where I invested a bunch of time and still could not resolve a VMware audio problem. This seemed to be the opportunity to try running IrfanView, a Windows program, in Ubuntu. I planned to do so via Wine, which (in that wacky Linux way) is short for "Wine is not an emulator." The stable release of Wine at this point was 1.0.1, and that is the version that was available in Ubuntu's (System > Administration > ) Synaptic Package Manager. I searched for wine in Synaptic, marked it, and clicked Apply. It downloaded and installed the necessary stuff. Next, following the steps I had researched when I had tried Wine a year earlier, I proceeded as follows, typing these commands into Ubuntu's (Applications > Accessories > ) Terminal at the command prompt:

wget http://www.kegel.com/wine/winetricks

sh winetricks mfc42

Then, in Ubuntu's File Browser (Places > Computer), I navigated to the folder where I had saved the downloaded IrfanView program. This program was called iview425_setup.exe. I copied the Location of this folder from the address bar at the top of File Browser and put it, between quotation marks, after a cd command in Terminal, as follows:

cd "/media/CURRENT/Miscellany/Installation/Programs"

and then I typed the Wine command to install IrfanView:

wine iview425_setup.exe

This gave me the regular IrfanView Setup dialog, just as if I had been installing it in Windows. I told it to install a link on the desktop, and it did; but I could not get that link to run. So I used cd again, to get to where it had been installed (cd "/home/ray/.wine/drive_c/Program Files/Irfanview", where "ray" was my username), and typed wine iv_uninstall.exe. This removed everything except iv_uninstall.exe itself from that folder; I deleted that last file manually.

I decided to try an older, simpler version of IrfanView. I went to OldApps.com and downloaded IrfanView 3.0. Then, as above, I used cd to navigate to the place where the downloaded file was. In this case, the program (after extraction from the downloaded .zip file) was named i_view32.exe, so I used that instead of iview425_setup.exe in the installation command presented above, as follows:

wine i_view32.exe

Unfortunately, this installer did not run at all. About this time, I rediscovered Wine's reports on the various efforts people made to run different Windows programs under Wine. In particular, I found the reports on IrfanView. These, supplemented with the instructions and replies posted at Wine-Reviews.net, seemed to indicate that what I really needed was to use relatively recent versions of both Wine and IrfanView.

To get a version of Wine more recent than the one that was available in Synaptic (above), I had to modify Synaptic. That is, I had been using Synaptic out of the box, the way it came in the original Ubuntu installation; but Synaptic could be configured to look in additional places for more software. In this case, I wanted it to look in the WineHQ repository. So I went back into Synaptic and clicked on Settings > Repositories > Third-Party Software > Add. In the APT line box, following the WineHQ instructions for Ubuntu 9.04, I typed this:

deb http://wine.budgetdedicated.com/apt jaunty main #WineHQ

Then I clicked on Add Source. Next, while still there in Software Sources, I went to the Authentication tab and clicked on Import Key File. I didn't have the key file yet, so I had to go to the webpage that they call Scott Ritchie's Key to get it. I saved that page (in Firefox, the command is File > Save Page As). Its default name was Scott Ritchie.gpg, so I accepted that. So now, back in the Software Sources > Authentication > Import Key File window, I navigated to where I had saved Scott Richie.gpg and selected it. Then I clicked on Close > Close. Now, back in Synaptic, I clicked Reload. I could have done a Quick Search, there in Synaptic, to see that Wine now needed to be updated; but I decided instead to update everything on my system that might need to be updated at that point. So I closed Synaptic and went to System > Administration > Update Manager and installed everything it had for me.

Normally, it can be more convenient and/or easier to remember one's way around by using the Graphical User Interface (GUI), as just described. In this case, though, for some reason the whole thing about Scott Ritchie was a little weird and hard to remember (though not Scott Richie himself, oh, no, we'll never forget ol' Scott), and I would probably have found it simpler just to copy and paste these lines into Terminal from the bottom of the WineHQ instructions page:

wget -q http://wine.budgetdedicated.com/apt/387EE263.gpg -O- | sudo apt-key add -

sudo wget http://wine.budgetdedicated.com/apt/sources.list.d/jaunty.list -O /etc/apt/sources.list.d/winehq.list

sudo apt-get update

sudo apt-get install wine

but whatever. It was done, and I had my other updates to boot. Plus, I got a free opportunity to screw around with Synaptic. (Later, I discovered that I should have uninstalled the older version of Wine first. I also discovered that apparently I should have been doing my work in a folder dedicated to Irfanview.) Now, at any rate, I had some more recent version of Wine installed. To see which one, I went back into Synaptic and searched for Wine again. It was 1.1.26. This was more bleeding-edge than the 1.1.14 that they had used in that Wine-Reviews article. I wasn't sure how to get back to 1.1.14, though, and anyway that was a half-year earlier, and they were using Ubuntu 8.04, so maybe this was better for my purposes. The Wine-HQ report indicated that Sven Plaga had just recently used 1.1.25 with great success. The version of IrfanView that Sven had used was apparently 4.25. He had used it with a beta release of Ubuntu 9.10, which I wasn't up to yet; but if it worked now, I figured that might defer whatever updating I might otherwise have to do later.

So now I tried again to install IrfanView on this newer version of Wine. I had already done the whole winetricks and mfc42.dll routine (above), so this simplified the process for me. Following the Wine-Reviews and Wine-HQ instructions and comments (with some help from some older Ubuntu Community Documentation), I repeated the foregoing steps of navigating to the folder where I had stored iview425_setup.exe, and then I typed this:

wine iview425_setup.exe

The installer ran, but again I couldn't get IrfanView to start. This time, though, it was not surprising. According to the instructions, I next needed to go into the installation directory (in my case, /home/ray/.wine/drive_c/Program Files/IrfanView) and delete the i_view32.ini file. The comments indicated that IrfanView would replace it with a simpler i_view32.ini that would cause no problems. I had forgotten to download and install the IrfanView plugins, so I did that now:

wine irfanview_plugins_425_setup.exe

Now I had an embarrassment of riches, in terms of IrfanView launchers. There were three different Ubuntu icons on my desktop, and they all worked. I deleted the two that didn't have the Ubuntu red cat (or whatever that is) on them. I also saw that Wine had installed itself as an option under Applications on the Ubuntu menu, and under Wine > Programs I had an IrfanView menu plus an apparent freebie, a link to an actual working copy of Notepad.

The key question, now, was whether IrfanView would now function in Ubuntu as it had functioned in Windows, for purposes of listening to and moving through .wav files. I went into IrfanView's Options > Properties and adjusted the settings to my preference. Then I double-clicked on an audio file . . . and watched it open in Totem Movie Player. OK, so this was my opportunity to learn how to set the default application program in Ubuntu. I started to Google for some guidance, and then I realized this was probably somewhere under System > Preferences - and, sure enough, there it was: Preferred Applications. I went to Multimedia and indicated that I wanted to use a Custom multimedia player. I right-clicked on the IrfanView desktop icon and went into its Properties > Basic tab. I copied its Command line to Terminal, to try it out. It worked: IrfanView started. So then I copied that same command line into the Multimedia command box. But either way, with or without the "Run in terminal" box checked, it didn't default to IrfanView; I was still getting Totem. So yes, I had to Google the question after all. The answer was easy enough (apparently a lot easier than it had been a year earlier): right-click on a .wav file and select Properties > Open With > IrfanView > Close.

Ah, but now, when I double-clicked on a .wav file, I got an error message:

Error: Windows can't play this file! Windows error text: Invalid MCI device ID. Use the ID returned when opening the MCI device.. You can try to install additional video/audio codecs from this site: http://www.fourcc.org/indexcod.htm or try the DirectShow option in Properties->Video.

Weird thing: I got that same error message three or four times in a row. I'd click OK, and there it would be again. And then, when it stopped, I got a little "No Device" window and the audio file played after all. But then that No Device window wouldn't go away; I had to kill IrfanView to banish it. I went into IrfanView's Properties and tried clicking the DirectShow option as advised. Same result. Seeking truth, I went back to Google. And I could tell that I was at last getting close to the truth indeed, because this time my search turned up only a small number of results, none of which seemed relevant. Fortunately, I was able to revise my search into something even less helpful. As the day drew to a close, I posted a question on this at Wine-HQ. Someone there suggested that I should post it as a bug in Wine, so I did that. I didn't know how long it would take them to address and resolve this bug, if that's what it was, so I decided it was time to post this message as-is and think about other ways of getting Irfanview to work.