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: Finding a DIR Alternative

I needed a DIR-type listing that would provide extended information about a file:  its name, date, and size, and also its path (i.e., the folder and subfolder where it was located), all on a single line of output.  DIR didn't seem to be capable of this, and neither did the utilities I found with a search (e.g., Karen's Directory Printer).

Another search raised the possibility that certain Linux utilities brought over to Windows might have this kind of capability.  I didn't want to run a Linux virtual machine on Win7; I just wanted to be able to run Linux commands that might add functionality I wasn't getting in Windows 7.

Linux commands were probably not the only alternative.  For instance, I could have learned how to use Windows PowerShell scripts.  My general impression of the Microsoft approach (as in the contrast between original BASIC and VB) was that, unfortunately, something that could be done with one relatively simple command in another tool would require three or four lines of code, which I would be able to write only after mastering a handful of relatively abstruse programming concepts, in the Microsoft product.  This impression seemed borne out when a search led to an indication that the DIR equivalent in PowerShell would require a multiline FOREACH loop.

Preliminary inquiries gave me the impression that Cygwin sought to provide a subsystem that would emulate a Linux machine within Windows.  There were indications that other projects (e.g., MSYS) sought to provide a somewhat comparable (e.g., 110MB) environment.  These seemed a tad heavy for my purposes; I was looking for something more like GnuWin, which was described as relying "only on libraries provided with any standard 32-bits MS-Windows operating system" and as not needing any Unix emulation.  Ideally, I would have some cool, relatively simple Linux-like commands available at the Windows command prompt.

By this point in my investigation, several people had mentioned CoreUtils.  This turned out to be a package within GnuWin.  The CoreUtils homepage described it as "the basic file, shell, and text manipulation utilities of the GNU operating system."  GNU was "a Unix-like operating system," in development since 1983, that apparently provided most of the materials used by Linux (which was, in turn, the source of Debian Linux, from which Ubuntu was built).

To clarify, it appeared that the CoreUtils existed in GNU, and there was an offshoot called CoreUtils for Windows.  Apparently this was what I would be getting through GnuWin.  There were other approaches to this sort of thing (e.g., Gow, UTools, UnxUtils), but my sense at this point was that GnuWin was dominant in this category.

I looked at the list of tools included in CoreUtils (for Windows).  I didn't count them, but I thought I remembered seeing an indication that there were more than 100 of them.  They were grouped into three main categories:  file utilities, text utilities, and shell utilities.  In the file utilities group, the description of the ls command was simply "lists directory contents,"; and vdir would apparently provide a "long directory listing."  These sounded like what I needed.  Examples in the text utilities category included comm ("compares two sorted files line by line") and uniq ("remove duplicate lines from a sorted file").  Examples in the shell utilities category included sleep ("suspends execution for a specified time") and uname ("print system information").

Although I could have just clicked on a download link, I went into the folder for the latest version and saw that it had not been updated since 2005.  This made me wonder whether I should have opted instead for Gow (short for GNU on Windows), which had apparently been updated as recently as November 2011.  I found a spate of (1 2 3 4 5) brief summaries of Gow published about that time.  Their similarities raised the thought that they may have been written from similar press releases.  Not that that would necessarily be bad.  Any product being promoted in 2011 could count as fresh air against a 2005 alternative.  But it was not reassuring that none of these explained clearly whether Gow was genuinely different, or just a borrowing, from the seemingly better-documented and more widely used GnuWin.  I found a page stating that Gow had been developed by a corporation in 2010 and used for some years before being released as open source.  This appeared to be an authoritative page.  It puzzlingly characterized GnuWin as being appropriate "if you want just one or two utilities."  A list of Gow utilities seemed similar, at a glance, to the GnuWin list (above), though I noticed that it did not have vdir.  The seeming mischaracterization of GnuWin, combined with the sense of evasion in the press-release writeups, persuaded me to stick with Plan A.

So now I did download and install the executable (exe; not src.exe) version of CoreUtils (6MB).  But, weird thing, they didn't give me a way to run the program.  My Start Menu had links to several PDFs.  Actually, it was rather messed up: they gave me four shortcuts to a total of two PDFs, and some of those links were buried about five layers deep in superfluous subdirectories. They also gave me two links to CoreUtils Help files that, when I clicked on them, gave me the familiar "Why can't I get Help from this program?" message that Windows 7 kindly provided when I would try to run Help files written for Windows XP.

Obviously, I ignored the manuals' actual contents and went looking for a way to run the program.  Weird thing:  I had all these redundant and dysfunctional help materials, and a link to an Uninstall routine, but no actual "Run CoreUtils" shortcut. I was half-tempted to uninstall them as defective, when it occurred to me that, well, they're supposed to be run from the command line, not the Start Menu.  So, OK, I went to the command line and typed "ls."  Windows said, "'ls' is not recognized as an internal or external command, operable program or batch file."  Hmm.  The manual, then, if I must.  Or manuals, I should say:  a regular-looking manual and also what appeared to be the set of Linux MAN (i.e., manual) pages, both in PDF format.  Neither had installation instructions.  I went to the ls MAN page.  It seemed to say that "ls -a" would be a working command.  Well, not on my machine, it wasn't.

I rooted around and found an article on how to use CoreUtils.  It said that I would have to adjust the PATH environment variable to tell the system where to look for the CoreUtils command instructions.  My way of applying those instructions was as follows:  first, in Windows Explorer, find where the CoreUtils executables (e.g., ls.exe) were installed.  On a 32-bit Windows 7 system, the location would probably be C:\Program Files\GnuWin32\bin; on a 64-bit system, C:\Program Files (x86)\GnuWin32\bin.  With that folder selected, click on the address bar at the top of Windows Explorer, make sure the whole address was highlighted (Ctrl-A if necessary), and copy the address (Ctrl-C).  Now I went to Start > Run > SystemPropertiesAdvanced.exe (could have used sysdm.cpl and then the Advanced tab) > Environmental Variables > System Variables > highlight Path > Edit > hit the End key.  There, I typed a semicolon (";") and then pasted in what I had copied from the Windows Explorer address bar.  (Could have typed it manually, using the 32-bit or 64-bit address just shown, but this was more accurate and it also forced me to verify the actual location.)  I OKed out of there and tried ls -a again on the command line.  Did I have to reboot to make the Path take hold?  Yes.  That was it.  I had ls, and it listed files.

So now, how about getting all that information mentioned at the outset -- path, date, etc., all on one line?  First question:  how could I get command-line command help?  In Windows, it was DIR /?.  But the /? option gave me an error with ls.  "man ls" didn't work either.  Page 9 of the manual PDF said the MAN pages were no longer being maintained.  I wasn't sure if that applied to what looked like the MAN pages included with GnuWin.  There wasn't a MAN MAN page in that PDF.  Page 10 said --help might work.  I tried "ls --help" and experienced satisfaction.  What I was seeing there looked like what appeared on pages 50-52 of the man PDF, pages 60-70 of 176 (text pages 52-62) in the more explanatory help PDF.  I wasn't inclined to read 11 pages to figure out how to get my directory listing.  Skimming down through the ls --help output, I tried "ls -l -N -R."  Good, but no cigar:  the path wasn't on the same line as the filename; no improvement over DIR.

The user's guide PDF didn't seem to think that there actually was a way to print the file's path on the same line as its date, filename, etc.  And so there I was.  I had come all this way with faith in my heart for the infinite possibilities of Linux.  I fervently believed that, with GNU, anything was possible.  But now, with my limited knowledge of Linux and such, cruel reality was saying Bismillah, no! we will not let you have all that stuff on one line of output.  There actually probably was a way to do it with some other tool, like the awe-inspiring grep, available in a different GnuWin package.  But I wasn't quite ready to go there.  In this project, grep looked, for me, like a bridge too far.

I thought about posting a question in the GnuWin Help forum.  But there had only been a handful of posts there in the last couple of months.  I also thought about going down the list of other utilities contained in CoreUtilities, so as to demonstrate to myself that this hadn't been a wild goose chase.  I thought about trying Gow after all, just in case its version of ls had different capabilities.  I thought about working up a kludge in which I would do a listing of all directories first (with e.g., "dir /ad /s /b") and then try to invent a way to append the pathname to each file line.

But before pursuing those rather lame possibilities, I noticed TCC/LE, advertised as a complete, powerful replacement for Windows CMD.  (TCC was short for "Take Command Console.")  It got 3.5 stars from 43 voters at Softpedia, only a solitary vote (five stars) at CNET -- but it had apparently been updated there just a few days earlier.  At MajorGeeks, it averaged 4.07 from 38 voters.  The description said it had enhanced commands (specifically including DIR) with new options.  A search didn't encourage the sense that there was a regular category of this sort of thing, with lots of competitors.  I downloaded and installed it.  The installation process seemed pretty slick, ending with a direct ride to their forums.  The installation left me with an open CMD window with a funky prompt, though apparently it was actually their own version of a command window.  (I did have another Win7 command window open throughout the installation.  It remained functional; I was able to close and open a new one after installation.)  I typed Help at their command prompt and went straight into their GUI help dialog, which actually made me say "Wow."  It wasn't spectacular; it was just good, and helpful, which I guess counts as spectacular after a long slog.  I replaced their ugly prompt with the ordinary Windows one by typing "prompt $P$g" at the prompt, though not without first amusing myself with variants (e.g., "Now what?").

Eventually I discovered that their help dialog was more or less the same as their online help page.  The manual had a large number of further instructions on how to tinker with the prompt and, it seemed, everything else.  Typing "option" at the prompt brought up settings, but not an obvious way to preserve prompt settings between sessions; it appeared the answer to that might lie somewhere within their SET command.  Anyway, I found information on their DIR command almost instantly, and also got a cursory version of it by typing dir /? at their prompt.  It led me to PDIR, and there I found the answer I was looking for.  What I had to type in a TCC/LE command window was this:

pdir D:\ /s /(dy-m-d zc fpn) > dirlist.txt

That gave me all of the information I was looking for, on a line-by-line basis, for every file on drive D, output into dirlist.txt.  Specifically, with the options in that sequence, I got the date (y-m-d), size (with commas), and the file path and name.

I took a quick look at their list of Commands by Category.  I also saw that they had a number of video and textual tutorials.  An impressive program.  But in any case, this investigation was done.

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.