Re: Owner/Group showing up as "??????????" on some Windows files despite mkpasswd/mkgroup

Larry Hall (Cygwin) wrote: > > On 1/2/2011 9:09 AM, aputerguy wrote: >> Csaba Raduly-2 wrote: >>> >>> On Sun, Jan 2, 2011 at 7:59 AM, aputerguy wrote: >>>> If trustedinstaller is a valid file owner then I would like it to show >>>>

Re: Owner/Group showing up as "??????????" on some Windows files despite mkpasswd/mkgroup

Csaba Raduly-2 wrote: > > On Sun, Jan 2, 2011 at 7:59 AM, aputerguy wrote: >> If trustedinstaller is a valid file owner then I would like it to show up >> as >> the file owner in cygwin so that rsync transfers it over properly. >> Presumably this would mean ad

Re: Owner/Group showing up as "??????????" on some Windows files despite mkpasswd/mkgroup

Larry Hall (Cygwin) wrote: > > On 12/29/2010 11:46 PM, Jeffrey J. Kosowsky wrote: >> When I do an 'ls -al' (or a getfacl) on some files, I get: >> owner/group = ???/???, implying that the numeric uid/gid are >> not found in the passwd/group file. >> >> This occurs even though I ran: >>

Should LANG be set or left unset?

I notice that by default LANG is unset. Is it best to leave it that way or would it be better to set it to something like LANG=en-US.UTF-8 (or even C) Note I am using Cygwin ver 1.7 -- View this message in context: http://old.nabble.com/Should-LANG-be-set-or-left-unset--tp27165212p27165212.htm

Re: ntEmacs has trouble with cygwin terminal...

Andy Koppe writes: > 2010/1/11 aputerguy >> Note though that there are good reasons why I use ntEmacs and not >> cygwin Emacs > > Such as? Well 2 main reasons. First, I use emacs all the time and keep it open my whole session long. Now sometimes when upgrading cygwin, I hav

ntEmacs has trouble with cygwin terminal...

Here is the situation: Running from a cygwin 1.7 bash terminal: $ emacs -nw $emacsclient -nw *ERROR*: Not using an ASCII terminal now; cannot make a new ASCII frame $echo $TERM cygwin Running from within screen within cygwin: $ emacs -nw emacs: standard input is not a tty $ emacsclient -nw *

Re: bash process substitution hangs with ssh

And interestingly, the mkfifo version still dumps core even with 'ssh -n' I'm confused... -- View this message in context: http://old.nabble.com/bash-process-substitution-hangs-with-ssh-tp26983912p26983991.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports:

Re: bash process substitution hangs with ssh

OK I got it to work by using 'ssh -n' since I guess otherwise it was waiting to read from stdin. Not sure though why it works without '-n' in Linux... -- View this message in context: http://old.nabble.com/bash-process-substitution-hangs-with-ssh-tp26983912p26983985.html Sent from the Cygwin lis

Re: bash process substitution hangs with ssh

The problem also seems to affect named pipes: i.e. $ mkfifo mypipe $ ssh remotemachine cat remotefile > mypipe Segmentation fault (core dumped) But $ cat localfile > mypipe works (note in both cases I read the pipe in another terminal using: cat < mypipe) -- View this message in context: h

Re: bash process substitution hangs with ssh

aputerguy writes: > ssh remotemachine cat remotefile> Note typo above. Should be: ssh remotemachine cat remotefile -- View this message in context: http://old.nabble.com/bash-process-substitution-hangs-with-ssh-tp26983912p26983920.html Sent from the Cygwin list mailing list arch

bash process substitution hangs with ssh

Running the following command: cat <(ssh remotemachine cat remotefile) *hangs* on cygwin bash while working on linux bash. Note though that even on cygwin, the individual pieces seem to work, i.e.: ssh remotemachine cat remotefile> and cat <(cat localfile) both work. But combining the

Re: Cygwin bash regexp matching doesn't treat "\b" properly

Hugh Myers: > This might come across as slightly smart-assed, but if you wrote your > script in Perl, you wouldn't have the platform problem, nor the > word-boundary problem. True you would have a Perl problem, but that > would still be several orders of magnitude easier than trying to have > Li

Re: Cygwin bash regexp matching doesn't treat "\b" properly

Dave Korn writes: > Bash man page for '~=' refers to man regex(3) which refers to man regex(7) > which describes word boundary markers as below: > > $ [[ "foo" =~ [[:\<:]]foo[[:\>:]] ]]; echo $? > 0 > > $ [[ "foobar" =~ [[:\<:]]foo[[:\>:]] ]]; echo $? > 1 Thanks David! I had actually greppe'd bo

Re: Cygwin bash regexp matching doesn't treat "\b" properly

Just for the record, the following works: [[ "$proc" =~ (^|[^0-9])$foo([^0-9]|$) ]] ; echo $? where I use $foo to store the process number I am trying to match against -- View this message in context: http://old.nabble.com/Cygwin-bash-regexp-matching-doesn%27t-treat-%22%5Cb%22-properly-tp2650

Re: Cygwin bash regexp matching doesn't treat "\b" properly

aputerguy writes: > Perhaps, I could try adding white space as in > [[ " $proc " =~ " 456 " ]] > but not sure if that will always work. Actually it doesn't work. I guess I could try to try to prepend/postpend something like an 'x' to each element of $

Re: Cygwin bash regexp matching doesn't treat "\b" properly

OK - I think I found the answer which is that \b is a GNU extension not recognized in cygwin. So, I guess the question now is there an alternative way of recognizing word boundaries? In particular, I am trying to match a process id where $proc is a list of one or more processes (awk'd from ps).

Is there a more Linux consistent version of ps?

I have been wondering about this for a long time... The ps command on cygwin and Linux use incompatible options & flags and display incompatible output formats. Additionally, linux ps is much more feature rich. While I could live with fewer features, the incompatibility in basic input options an

Cygwin bash regexp matching doesn't treat "\b" properly

The following behavior differs between Cygwin bash (both versions 3.2.39, 3.2.49) and Fedora/Linux bash (both versions 3.2.33 and 4.0.33): $ [[ "foo" =~ \\bfoo\\b ]]; echo $? Cygwin: 1 Linux: 0 Cygwin returns 0 only if I remove the \\b from before and after the word 'foo' What is going on her

Re: 'ls' not finding owner/group of some files created by other user

Corinna Vinschen writes: > In that case, the problem probably occurs because userB has no > permissions to read the file permissions. Cygwin's chmod creates a > POSIX compatible ACL, which adds READ_CONTROL permissions for everyone. That seems to be the case here and would seem to explain it - t

Re: 'ls' not finding owner/group of some files created by other user

Corinna Vinschen writes: > It means it doesn't know the SIDs. They don't show up in /etc/passwd > and /etc/group. BUT THEY DO! And they must since why else would doing a trivial 'chmod' (that doesn't change anything) all of a sudden make them show up. $ subinacl /noverbose /nostatistic /file C:

Re: Seems like treatment of NTFS ADS (foo:bar) changed between 1.5 and 1.7 but not mentioned in What's Changed

I think it should still at least be documented as a change especially since a deliberate change. -- View this message in context: http://old.nabble.com/Seems-like-treatment-of-NTFS-ADS-%28foo%3Abar%29-changed-between-1.5-and-1.7-but-not-mentioned-in-What%27s-Changed-tp26363833p26370924.html Sent

Re: subinacl not consistent with getfacl under ssh login (USERNAME=SYSTEM)

OK - I just re-read the ntsec portion of the cygwin manual and found this paragraph: > This has the following unfortunate consequence. Consider a service > started under the SYSTEM > account (up to Windows XP) switches the user context to DOMAIN\my_user > using a token created > directly by ca

Re: Seems like treatment of NTFS ADS (foo:bar) changed between 1.5 and 1.7 but not mentioned in What's Changed

Andy Koppe wrote: 2009/11/15 aputerguy: >> why does >> cygwin 1.5 seem to encode it as \357\200\272 > What do you mean? 1.5 doesn't know anything about Unicode filenames. Well I'm using Putty to ssh into my Windows machine running cygwin 1.5 When I do tab completion

Re: How to capture stderr of dos process running in bash shell??

Dave Korn writes... > So, it just doesn't work, and that's using all MS software; it's not > going > to work any better in bash. I think you're probably out of luck here; I > don't > know any way to capture direct console output like that (short of some > sort of > screen scraper or even if you

Re: Seems like treatment of NTFS ADS (foo:bar) changed between 1.5 and 1.7 but not mentioned in What's Changed

Andy Koppe writes: > I'd suspect the support for ADSs in 1.5 was rather accidental anyway. > POSIX programs certainly don't know about them, and you get the rather > weird situation that "files" like foo:bar can be accessed but don't > show up in the directory they're in. Fair point. But also hav

Seems like treatment of NTFS ADS (foo:bar) changed between 1.5 and 1.7 but not mentioned in What's Changed

Cygwin 1.7 seems to have lost support for NTFS Alternative Data Streams -- which it seems not to either create or read (vs. Cygwin 1.5 behavior) -- specifically, $ echo "dog" > foo:bar $ echo "cat" > foo:baz $ cat foo:bar dog $ cat foo:baz dog In Cygwin 1.5 $ ls -s foo* 0 foo $ ls -1s foo:bar

Re: Would it be possible/hard to write a version of 'at' that executes "right away" to get around ssh username=SYSTEM?

And in case anyone is interested, here is a bash function that launches a command via 'at' at the next minute and returns the number of seconds until the launch (actually if you are less than 5 seconds before the next minute, it waits until the minute after so that at has time to setup - you could

Would it be possible/hard to write a version of 'at' that executes "right away" to get around ssh username=SYSTEM?

For a while, I have been using the "trick" of executing scripts via 'at' when logged in over ssh to get around the limitations of USRNAME=SYSTEM. This is necessary for running things like vshadow, dosdev, and apparently subinacl. While I have written a short script that figures out the nearest mi

Suggestion: Add links in /proc/registry for standard abbreviations like HKLM

I find /proc/registry is a nice shortcut for reading registry entries rather than having to use regtool/reg/regedit etc. It would be nice though if there were links for the commonly accepted shortcuts as used for example by regtool. Any reason not to add them within /proc/registry itself (of cou

Re: 'ls' not finding owner/group of some files created by other user

Jason DePriest wrote: > Does 'ls -n' show the UIDs under both users? ls -n shows uid=gid=4294967295 which I believe is UINT_MAX (2^32-1), so this is just -1. Maybe what's happening is that cygwin is returning an error (-1) here? BTW I'm running cygwin 1.7 -- View this message in context: http

subinacl not consistent with getfacl under ssh login (USERNAME=SYSTEM)

When I log in via ssh (and have the infamous USERNAME=SYSTEM), subinacl assigns *all* file and directory ownership to "nt authority\system" getfacl however still gets the ownership right. I assume this has something to do with the fact that ssh comes in as USERNAME=SYSTEM but it is a pita that su

Re: 'ls' not finding owner/group of some files created by other user

And the same thing occurs for directories created from Explorer. But again this problem doesn't occur for files or directories created within cygwin (e.g., touch, mkdir, cat >). -- View this message in context: http://old.nabble.com/%27ls%27-not-finding-owner-group-of-some-files-created-by-oth

Re: 'ls' not finding owner/group of some files created by other user

And also the parent directory has the following listing: drwxr-xr-x 1 userA Administrators 0 2009-11-14 19:10 -- View this message in context: http://old.nabble.com/%27ls%27-not-finding-owner-group-of-some-files-created-by-other-user-tp26355135p26355136.html Sent from the Cygwin list mailing lis

'ls' not finding owner/group of some files created by other user

This is a weird one. If I use a non-cygwin program such as 'edit' or 'ntemacs' to create a file under userA, say 'test', then when I list under user A, I get as expected: -rwxr--r--+ 1 userA None 0 2009-11-14 19:00 test* However, when I list under userB (who is non-privileged), I get: -rwxr--r--

Re: How to capture stderr of dos process running in bash shell??

Dave Korn writes: >Christopher Faylor wrote: >> >> Although, hmm, on rereading it isn't clear that the output shows up on >> the screen. It sounds like the DOS program just might not differentiate >> between stdout and stderr. Yes the output (both stderr and stdout) appear on screen > I chec

How to capture stderr of dos process running in bash shell??

I am trying to capture the error messages of 'subinacl.exe' (a dos program included with Windows 2003 toolkit) which I am running from a bash script. However both the stderr and stdout of the process seem to go to bash stdout since redirecting bash stderr (2>) doesn't seem to have any effect. I

Re: Can you clone entire cygwin setup from one pc to another

Corinna VInschen writes: > For exakt cloning including ACLs, I would suggest to use robocopy. Yes, > it's a native tool, but it's sort of a swiss army knife to do exactly > that job. You don't need to copy the registry entries. Thanks Corinna! When you say that I don't "need" to copy the regis

Re: Can you clone entire cygwin setup from one pc to another

I guess the other thing to worry about would be ACL entries. If there are any, I could solve that with getfacl/setfacl assuming that the ACL changes were addressable by getfacl/setfacl. And if not I could always use 'subinacl' to just clone the entire ACL structure of the C:\cygwin tree. -- View

Can you clone entire cygwin setup from one pc to another

I would like to clone the cygwin setup from one pc to another. Looking at the registry, it appears that at least in my case there are only a few registry entries with the text cygwin in them, including the %path% and several entries corresponding to the services I have set up (rsyncd, sshd, XWin)

Re: Suggestion: Have setup.exe warn before upgrading 'cgywin' package itself

Jeremy Bopp writes: > BTW, this is not only a problem for the cygwin package. Literally any > package could have files which are in use at the time of replacement. > So any solution would need to take that into account. True but sometimes the perfect is the enemy of the good enough... The 'cygwi

Suggestion: Have setup.exe warn before upgrading 'cgywin' package itself

Currently when upgrading the base 'cygwin' package, the installer only warns you midway through the installation after some files have been removed/replaced. If you have other cygwin processes running, you may be left in an incomplete state where you can't or don't want to kill the other cygwin p

Re: getfacl returns 0 if no file found

Corinnna writes: > 2 (solaris). Since getfacl is based on the Solaris tool, I'll implement > that return code. 1 is returned for usage errors. Works for me - as long as I can trap it -- View this message in context: http://old.nabble.com/getfacl-returns-0-if-no-file-found-tp26287360p26291764

getfacl returns 0 if no file found

This is inconsistent with Linux treatment - is that what we want? Because it would be good to be able to trap this as an error. $ getfacl sfdsfdsfdsf getfacl: sfdsfdsfdsf: No such file or directory $ echo $? 0 (cygwin) 1 (linux) -- View this message in context: http://old.nabble.com/getfacl-re

Re: Differences between 'ls' permissions *nix vs cygwin

Corinna Vinschen-2 writes: > On Nov 10 07:22, aputerguy wrote: > > I was unaware of that "feature" > > However, after turning it off, > Don't do that. There's more to this user right than you see at first > sight. A lot of stuff might not work

Re: Differences between 'ls' permissions *nix vs cygwin

Similarly, 'cd' seems to return a different error message on cygwin vs. Linux when looking at such subdirectories: $cd dir1 bash: cd: /root/dog: Permission denied [both cygwin & linux] $ cd dir1/ bash: cd: /dir1/: Permission denied [linux] bash: cd: dir1/: Not a directory Am I missing something

Re: Differences between 'ls' permissions *nix vs cygwin

Corinna Vinschen-2 writes: > http://www.google.com/search?q=%22bypass%20traverse%20checking%22 I was unaware of that "feature" However, after turning it off, it still seems that cygwin 'ls' gives a different response than *nix 'ls' to a file in the subtree of a directory that is "non-traversable

Differences between 'ls' permissions *nix vs cygwin

I'm not sure if this is a bug or a feature. But I find the following differences between *nix and cygwin on access permissions of 'ls' Test case: $ mkdir -p dir1/dir2 $ chmod 700 dir1 $ ls -d dir1 dir1 [both Linux & Cygwin] $ ls dir1 ls: cannot open directory dir1 Permission denied [both

Re: Finding junction points in cygwin

Christopher Faylor writes > It's not clear whom you are expecting to prepare this comprehensive > list. For Cygwin we clearly want you to use our symlinks. It's a > bonus that Corinna has implemented any functionality for anything > else at all. No real expectations and not a complaint about cy

Re: Finding junction points in cygwin

"DePriest, Jason R." wrote: > There is also the 'subst' command that lets you create a directory and > point it to a drive. OK - now I am truly tearing out my hair as 'subst' makes #11. I'm thinking a table with the following columns would be very helpful: A. Name of command B. Source (e.g., Cyg

Re: Finding junction points in cygwin

And also add to the below list: 10. mklink -- More generally, could someone point me to a single source that can accurately compare and contrast the following notions of "links" in cygwin/windoze: 1. Hard links (ln) 2. Soft links (ln -s) - Old style - New style 3.

Re: Finding junction points in cygwin

Corinna Vinschen writes: >On Nov 9 11:27, aputerguy wrote: >> The nice thing though about junction.exe is that it uses the *nix like >> '-d' >> flag rather than the dos-like '/D' flag that mklink seems to use. >mklink /d creates a symlink with a dire

Re: Finding junction points in cygwin

More generally, could someone point me to a single source that can accurately compare and contrast the following notions of "links" in cygwin/windoze: 1. Hard links (ln) 2. Soft links (ln -s) - Old style - New style 3. Windows shortcuts 4. Junctions created by junction.exe 5. Reparse poin

Re: Finding junction points in cygwin

I have been googling on junction.exe and mklink. Since they both create reparse points, in what way are the reparse points different to the extent that cygwin recognizes those from mklink but not those form junction.exe. The nice thing though about junction.exe is that it uses the *nix like '-d'

Re: Finding junction points in cygwin

Corinna writes: > Uh, I see. Don't use the junction tool, use cmd's mklink instead. > junction.exe creates directory symlinks which can't be easily recognized > as directory junctions, at least not using the default technique. > I'll look into supporting these weird junctions as well. Thanks. S

Re: 1.7] BUG - GREP slows to a crawl with large number of matches on a single file

Corinna writes: > I'm glad to read that, but I only debugged the problem. The Fedora > fix was applied by Chris. Well it works for me too and as the OP of the problem, I extend my thanks to both of you and all the others who helped in debugging and coming up with such a quick fix. My only remai

Re: Finding junction points in cygwin

Corinna Vinschen writes... > Indeed, and I can't reproduce this, neither in Cygwin 1.5.25, nor in > Cygwin 1.7. The only difference between your and my run is that I'm > using the cmd mklink builtin rather than the junction tool, like this: > BLODA? I don't know... I don't have a lot of BLODA o

Re: Finding junction points in cygwin

Corinna writes.. > Try Cygwin 1.7. It recognizes directory junctions as symlinks. $ uname -r 1.7.0(0.214/5/3) But don't see any symlinks... -- View this message in context: http://old.nabble.com/Finding-junction-points-in-cygwin-tp26260606p26270509.html Sent from the Cygwin list mailing list

Re: Finding junction points in cygwin

Actually the behavior is even stranger... renaming and then deleting junctions creates spurious directories. echo "This is a test file" >| targetfile mkdir targetdir echo "This is a test dir file" >| targetdir/targetdirfile junction.exe junctionfile targetfile junction.exe junctiondir targetdir

Re: Finding junction points in cygwin

Corinna Vinschen writes > Not quite. Directory junctions appear as symlinks. Volume junctions > are treated as simple directories since they are for all practically > purposes the same as Unix mount points. But I still see several issues at least with directory junctions. 1. When I use junction

Finding junction points in cygwin

Does cygwin have any ability to find/identify NTFS junction points? This would be useful so that you don't inadvertently mistreat them thinking they are regular files or directories. Also, is there any native cygwin utilities with functionality similar to junction.exe allowing you to make or dele

Re: 1.7] Can you have multipe cygdrive path prefixes active at once

I am currently using the following 'sed' one liner. It should work except in the case where your cygdrive prefix has two or more spaces in a row followed by the word 'system' or user' followed again by 2 or more spaces. Pretty unlikely but not impossible of course... mount -p | sed -ne "s/\(.*\S\

Re: 1.7] Can you have multipe cygdrive path prefixes active at once

Lee Rothstein wrote: > Does this not do what's required (barring spaces in the > "Cygdrive" alternative prefix): > > mount -p | gawk 'NR==2 { print $1 }' Unfortunately, your method would fail if there were *any* spaces in the pathname. Since regardless of what you say about the lack of "abject st

Why do 'find' and 'ls' act differently on ACLs

As a newbie to Windoze/ACL security, I am probably missing something. But... Why do 'ls and 'find' seem to treat the ACL restrictions differently. Specifically, 'ls /c/Documents and Settings/Administrators' works while 'find /c/Documents and Settings/Administrators' returns: find: `/c/Document

Re: 1.7] BUG - GREP slows to a crawl with large number of matches on a single file

Changing LC_ALL also solved the problem for me. But it begs the question of how many other basic and take-for-granted functions might be affected by this apparent UTF-8 slowdown. And again we, are not talking about some minor overhead, we are talking about a slowdown of 1500X or 150,000% As a

Re: 1.7] Can you have multipe cygdrive path prefixes active at once

Jeremy Bopp writes: > Well, it's a bit of a hack, but you could try something like the > following: > > $ dirname $(cygpath -u C:/) > This assumes that there is always a C: drive and converts the path to > the root of that drive into a POSIX path which will include the cygdrive > prefix. Then d

Re: 1.7] Can you have multipe cygdrive path prefixes active at once

Jeremy Bopp writes: > The concern posed by the instigator of this thread is that it can't be > known from the output of "mount -p" whether or not the spaces which > follow the listed cygdrive prefix are part of the prefix or padding for > the outputted columns. It should be pretty rare that some

Re: 1.7] Can you have multipe cygdrive path prefixes active at once

In particular, I can't use "mount -p" to distinguish between prefixes that might have (variable) number of trailing spaces (which is allowed). -- View this message in context: http://old.nabble.com/1.7--Can-you-have-multipe-cygdrive-path-prefixes-active-at-once-tp26227605p26227607.html Sent fro

1.7] Can you have multipe cygdrive path prefixes active at once

The mount manpage says: -p, --show-cygdrive-prefix show user and/or system cygdrive path prefix The and/or would suggest you could have different user and system cygdrive path prefixes active at once, which would potentially be a bit confusing Also, is there a better way to

Re: 1.7] BUG - GREP slows to a crawl with large number of matches on a single file

OK. Here is a simple test case: X=10 while [ $X -gt 0 ] ; do echo "The quick brown fox jumped over the lazy dog" ; let X=X-1; done > testfile time grep dog testfile | wc Cygwin 1.5: real0m0.219s user0m0.232s sys 0m0.045s Cygwin 1.7: real7m46.575s user7m14.138s sys

Re: Is there a fast way to get acl's for the whole filesystem (or chunk thereof)

OK... one small problem. Every ~4500 lines and (70-80K characters), both of these methods omit the empty line between the getfacl stanzas. The skipped lines however don't occur at the same places in the two different methods. I assume it must be due to buffering of the long line input or somethin

Re: Is there a fast way to get acl's for the whole filesystem (or chunk thereof)

Andrew Schulman-3 wrote: > getfacl -R? Unfortunately, no '-R' at least on my updated version. The "-exec ... \+" and the "-print0 | xargs -0" tricks both worked!!! Thanks. Timing and comparing the two approaches, it seems like they both use the same 'user' time but the xargs approach uses only

1.7] BUG - GREP slows to a crawl with large number of matches on a single file

Running grep on a 20MB file with ~100,000 matches takes an incredible almost 8 minutes under Cygwin 1.7 while taking just 0.2 seconds under Cygwin 1.5 (on a 2nd machine). The following cases show how grep under 1.7 grinds to a halt as the number of matches increases. The data 'testfile' is a pla

[1.7] Do the new security enhancements allow ssh under your own $USERNAME

I read the materials in "What's New" and the section "Windows Security in Cygwin" with interest since it describes new authentication potentials. However, I did not understand the material well enough to know whether 1.7 will allow users to ssh under their own $USERNAME or whether you will always

Is there a fast way to get acl's for the whole filesystem (or chunk thereof)

For backup, I am trying to dump a list of the acl's for the files being backed up since my backup program doesn't handle the acls. When I use something like: find /c -exec getfacl {} \; > mysavefile It is slow, in part at least because it has to fork a call to getfacl on each file found. Is t

Re: Accessing GLOBALROOT paths - a potential compromise???

Corinna Vinschen writes: > In Cygwin 1.7 you can do this for any subdir in your volume shadow copy: > > $ ls -l //?/GLOBALROOT/Device/HarddiskVolumeShadowCopy1/subdir > > It just doesn't work for the root directory of a drive due to internal > path handling restrictions. But there's a simple wo

Re: [1.7] Undocumented change in accessing by dos drive letters?

> Larry Hall (Cygwin) writes > On 11/02/2009 01:29 PM, Jeffrey J. Kosowsky wrote: >> I didn't see any documentation in the What's New/What's Changed >> document saying that the following no longer works: >>: >> For example: >> $ ls C: >> ls: cannot access C:: No such file