from:"aputerguy"


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:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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 list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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: 
http://old.nabble.com/bash-process-substitution-hangs-with-ssh-tp26983912p26983954.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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 archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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 two fails.

Any thoughts on what may be wrong here?
-- 
View this message in context: 
http://old.nabble.com/bash-process-substitution-hangs-with-ssh-tp26983912p26983912.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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
> Linux, Cygwin and Posix come to agreement!! :)

As soon as Perl becomes the default shell...

Seriously, there are times to use Perl and times not to...
But launching perl seems a bit of overkill when I just have to do a simple
match in a .bashrc script or when I need a small shell script wrapper.

-- 
View this message in context: 
http://old.nabble.com/Cygwin-bash-regexp-matching-doesn%27t-treat-%22%5Cb%22-properly-tp26500158p26504147.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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 both regex(3) and regex(7) before but I was looking
for the word "word" or "boundary" - neither of which are used in this
context.

HOWEVER, this solution while sweet for cygwin-bash, has the CONVERSE
PROBLEM.
Apparently, the special strings [[:<:]] and [[:>:]] are not recognized under
Linux regex(7) - they give return code 2.

So, now I have the frustrating situation where \\b works in Linux but not in
Cygwin while [[:<:]] works in Cygwin but not in Linux.

BTW, both regex(7) pages even imply they are POSIX.
Linux: "regex POSIX.2 regular expressions"
Cygwin: "regex - POSIX 1003.2 regular expressions"

Such incompatibility is a PITA because then in a mixed Windows/Linux
environment one has to remember to clutter scripts with ugly "if [ "$OSTYPE"
= "cygwin" ] exceptions, etc.

-- 
View this message in context: 
http://old.nabble.com/Cygwin-bash-regexp-matching-doesn%27t-treat-%22%5Cb%22-properly-tp26500158p26503748.html
Sent from the Cygwin list mailing list archive at Nabble.com.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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-tp26500158p26503082.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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 $proc, but that seems really kludgey
-- 
View this message in context: 
http://old.nabble.com/Cygwin-bash-regexp-matching-doesn%27t-treat-%22%5Cb%22-properly-tp26500158p26501030.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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). 
So, for example, I want to make sure that if $proc="123 456 789" that "456"
matches but not "45"

Perhaps, I could try adding white space as in 
[[ " $proc " =~ " 456 " ]]
but not sure if that will always work.

So, what is the best way to do this without the "\\b" word boundary symbol?
-- 
View this message in context: 
http://old.nabble.com/Cygwin-bash-regexp-matching-doesn%27t-treat-%22%5Cb%22-properly-tp26500158p26500814.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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 and the lack of consistent output format is a PITA since it breaks
many of my scripts. Compatibility here is important since 'ps' is such a
basic script building block used all the time to get info about other
processes.

Now I could understand that differences in Windows and Linux architecture
could lead to some features being implementable on one platform vs. the
other, but I don't understand why there seems to be little if any consistent
overlap.

Perhaps this is all a POSIX vs. not POSIX thing or something like that but I
would like to understand what the advantages are of the current approach and
why in particular the 'ps' on cygwin seems so underpowered and inconsistent.
-- 
View this message in context: 
http://old.nabble.com/Is-there-a-more-Linux-consistent-version-of-ps--tp26500161p26500161.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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 here?
-- 
View this message in context: 
http://old.nabble.com/Cygwin-bash-regexp-matching-doesn%27t-treat-%22%5Cb%22-properly-tp26500158p26500158.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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

2009-11-16 Thread aputerguy

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 - thanks!
BTW, it seems that chmod also adds FILE_READ_ATTRIBUTES though READ_CONTROL
is all that was needed to solve my problem.

Also, for the record, it seems that 'cp -a' does similar except it also
*deletes* the SYSTEM ACL attributes of DELETE, WRITE_DAC and WRITE_OWNER.
It's not intuitively obvious to me why 'cp -a' would degrade permissions...

That being said is there (or should there) be a flag to 'cp' that will
strictly preserve 'all' ACL attributes in a similar way to how Linux has the
-Z flag to preserve SELinux context?
(cp -r --preserve=all doesn't do so)
I had always (mistakenly) assumed that 'cp -a' would do a "pristine" job of
copying -- it would be nice to have a cygwin tool that would be pristine
that way without having to go to Windows tools.

I apologize for all these maybe newbie-like questions but I am still used to
*nix rwx permissions and in this case even getfacl didn't help. I needed to
go to my new "friend" subinacl to see what you were saying - wasn't obvious
to me at least.

--
View this message in context:
http://old.nabble.com/%27ls%27-not-finding-owner-group-of-some-files-created-by-other-user-tp26355135p26377078.html
Sent from the Cygwin list mailing list archive at Nabble.com.

--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple

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

2009-11-16 Thread aputerguy


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:\\cygwin\\usr\\local\\bin\\testfolder
/findsid=S-1-5-21-1234567890-1234567890-1234567890-1005

+File C:\cygwin\usr\local\bin\testfolder
/control=0x0
/owner =mymachine\userA
/pace =mymachine\userA  Type=0x0 Flags=0x0 AccessMask=0x1f01ff

$ grep S-1-5-21-1234567890-1234567890-1234567890-1005 /etc/passwd
userA:unused:1005:513:U-mymachine\userA,S-1-5-21-1234567890-1234567890-1234567890-1005:/home/userA:/bin/bash

Note this error doesn't happen if I create a folder (using Windows tools) in
C:  but it does happen in all the other public places I tried, including:
/c/Program Files
/c/cygwin/usr
/c/cygwin/usr/local
/c/cygwin/usr/local/bin

-- 
View this message in context: 
http://old.nabble.com/%27ls%27-not-finding-owner-group-of-some-files-created-by-other-user-tp26355135p26371224.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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

2009-11-16 Thread aputerguy


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 from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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 calling the NtCreateToken function. A process running under
> this new access token might 
> want to know under which user account it's running. The corresponding SID
> is returned correctly, for
> instance S-1-5-21-1234-5678-9012-7. However, if the same process asks
> the OS for the user 
> name of this SID something wierd happens. For instance, the
> LookupAccountSid function will not return
> "DOMAIN\my_user", but "NT AUTHORITY\SYSTEM" as the user name.

> You might ask "So what?" After all, this only looks bad, but functionality
> and permission-wise everything 
>should be ok. And Cygwin knows about this shortcoming so it will return the
correct Cygwin username 
> when asked. Unfortunately this is more complicated. Some native,
> non-Cygwin Windows applications 
> will misbehave badly in this situation. A well-known example are certain
> versions of Visual-C++.

So is 'subinacl' just another example of these badly behaved non-Cygwin
applications?
If so, is there anything one can do other than to use one of the other
methods to get a properly authenticated ssh login?


-- 
View this message in context: 
http://old.nabble.com/subinacl-not-consistent-with-getfacl-under-ssh-login-%28USERNAME%3DSYSTEM%29-tp26355883p26366622.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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 on the "foo:bar" file it completes to
foo\357\200\272 but perhaps the Unicode is coming from the Putty terminal
(which is set to UTF-8) though somehow bash is preserving the encoding that
gets translated that way...

-- 
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-tp26363833p26366268.html
Sent from the Cygwin list mailing list archive at Nabble.com.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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 want a wooden table solution taking a
> snapshot
> and OCRing it...!)

True... just for the record, you can capture stderr to a file using the flag
/errorlog= or even dump it to /dev/null using /errorlog=$(cygpath -w
/dev/null) or equivalently /errorflag=\\.\NULL which to my surprise actually
worked. And once you have split off stderr, you are left with just the
output on stdout which is now in the bash world so you can treat it using
standard bash pipes and redirection.

I just couldn't figure out how to pipe the stderr -- since in my case I
wanted to pipe it through gzip before capturing it to a file. So, instead I
do the slightly less elegant thing of first capturing to a file and then
running gzip later on that file.

I do agree with you though that the original question is probably more a
question of a broken windows program and I'm thinking that the help is just
plain wrong in saying that the error is on stderr but rather I believe that
stdout and stderr are a single stream unless you use /errorlog to explicitly
fork it off to a file.

-- 
View this message in context: 
http://old.nabble.com/How-to-capture-stderr-of-dos-process-running-in-bash-shell---tp26341304p26366227.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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 having 'ls -s' return '0' on a non-empty file is pretty
weird too.

>  Hence I think the right way to
> access ADSs is via Windows tools. Unless there is a POSIXy way to
> represent them?

The key point of my posting was not to advocate for one or the other but
rather to give people a heads-up on this change in case anybody had written
code based on the old treatment. In particular, I suggest that such
fundamental (though certainly not at all common) changes to how files are
accessed/named should be mentioned in the "What's changed" section.

As a total lay-person to NTFS and filesystem stuff, I would have thought
that the thing to do would be to allow ":" to appear by escaping it "\:"
while preserving the original 1.5 ":" behavior to allow writing/reading to
NTFS ADS.

Finally, as an aside and for my edification, if the [] is U+F034, why does
cygwin 1.5 seem to encode it as \357\200\272 which is consistent with what I
get when I paste the filename into emacs (in UTF-8 encoding) and then look
at it in hexl mode which gives ef 80 ba (which is the hex equivalent of the
octal cygwin 1.5 codes).
-- 
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-tp26363833p26364830.html
Sent from the Cygwin list mailing list archive at Nabble.com.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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
1 foo:bar

$ ls -1s foo:baz
1 foo:baz

and explorer lists a single 0 byte file

In cygwin 1.7
$ ls -1s foo*
1 foo:bar
1 foo:baz

Which might seem ok,
*But* now explorer shows two files
foo[]bar
foo[]baz
where [] is a square box indicating an illegal symbol.

Basically it seems that rather than using the NTFS ADS, that cygwin 1.7 is
treating ":" as a valid symbol for file names and is actually creating two
separate files.

Perhaps even worse, cygwin 1.7 can't seem to read NTFS ADS files created on
1.5 (nor do I see how to create NTFS ADS with 1.7)
i.e., if I create 'foo' as above on 1.5 and try to read it on 1.7, I get:

$ ls -1s foo*
0 foo

$ cat foo
$

$ cat foo:bar
cat foo:bar: No such file or directory

$ cat foo:baz
cat foo:bar: No such file or directory

Conversely, foo created in 1.7 also gives 2 separate foo???bar and foo???baz
in 1.5

So again it seems like:
1]  1.7 treats ":" like a regular filename symbol and creates a regular file
2] 1.7 can't read NTFS ADS since as above it sees ":" as just a regular
character.

I imagine this was done for POSIX compliance but does this mean that there
is no longer support for NTFS ADS and that such files are neither creatable
nor readable under 1.7?
Also, shouldn't this be documented in "What's changed"
-- 
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-tp26363833p26363833.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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
probably use a number smaller than 5 seconds of course)

function at_launch ()
{
local h m s wait command
command=$@
set -- $(date +"%H %M %S")
h=$((10#$1))  #Note explicitly use base 10 so that 08 and 09 not
interpreted as bad octal
m=$((10#$2 +1)) #Advance minutes by 1
s=$((10#$3))
wait=$((60 - $s))
[ $s -gt 55 ] && let "m += 1" "wait += 60" # Make sure >5 seconds left
[ $m -ge 60 ] && let "m %= 60" "h += 1" #Overflow minutes
let "h %= 24"
at $h:$m $(cygpath -w $(which bash.exe)) -c \"$command\" > /dev/null
return $wait
}
-- 
View this message in context: 
http://old.nabble.com/Would-it-be-possible-hard-to-write-a-version-of-%27at%27-that-executes-%22right-away%22-to-get-around-ssh-username%3DSYSTEM--tp26362968p26363163.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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 minute, it
is kludgey and a pita to have to wait until the next minute for at to run.
Which got me thinking that why not write a cywin version of at with better
time granularity so that the command would run essentially right away. This
would then be a poor man's version of 'sudo' though it probably couldn't be
interactive.

I'm not a system programmer so I have no clue how hard this would be but it
seems like it could be very useful...
-- 
View this message in context: 
http://old.nabble.com/Would-it-be-possible-hard-to-write-a-version-of-%27at%27-that-executes-%22right-away%22-to-get-around-ssh-username%3DSYSTEM--tp26362968p26362968.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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 course, I could
always create my own links from a real directory but it would be nice to
have it built in)
-- 
View this message in context: 
http://old.nabble.com/Suggestion%3A-Add-links-in--proc-registry-for-standard-abbreviations-like-HKLM-tp26360971p26360971.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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://old.nabble.com/%27ls%27-not-finding-owner-group-of-some-files-created-by-other-user-tp26355135p26360860.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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 subinacl doesn't work properly under
ssh -- specifically, I can't use subinacl remotely via ssh to administer a
machine.

Any thoughts on why this is so and whether it can be fixed?
-- 
View this message in context: 
http://old.nabble.com/subinacl-not-consistent-with-getfacl-under-ssh-login-%28USERNAME%3DSYSTEM%29-tp26355883p26355883.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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-other-user-tp26355135p26355880.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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 list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

'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--+ 1   0 2009-11-14 19:00 test*

Now if under userA, I do something seemingly innocuous, say: chmod u+r test
which doesn't even change any permissions (nor ACL's for that matter), the
listing under userB is now correct.

This doesn't happen when I create files in bash directly say by using
'touch'.


Also the ACL for the file is nothing weird for that matter:
# owner: userA
# group: None
user::rwx
group::---
group:SYSTEM:rwx
mask:rwx
other:---

And 'traverse files' is on.

What is going on here?






-- 
View this message in context: 
http://old.nabble.com/%27ls%27-not-finding-owner-group-of-some-files-created-by-other-user-tp26355135p26355135.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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 checked: you can't redirect its error output at all, even in a genuine
>cmd.exe shell with cygwin having nothing to do with it.  It must indeed be
>using the console directly.Curiouser and curiouser...
it
>links msvcrt.dll and imports printf and wprintf, but then it goes and
actually
>does everything the hard way with lowlevel console i/o in unicode.  How
peculiar.

Strange. What is meant then by this sentence included in the help:
   "SubInAcl error messages are sent to the Standard error."


-- 
View this message in context: 
http://old.nabble.com/How-to-capture-stderr-of-dos-process-running-in-bash-shell---tp26341304p26354920.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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 assume this is because the dos process is running in a bash shell.

Still, I was wondering whether there are any 'tricks' to somehow capture it.
-- 
View this message in context: 
http://old.nabble.com/How-to-capture-stderr-of-dos-process-running-in-bash-shell---tp26341304p26341304.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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 registry entries, what do I do
then to copy over the services?
Do I just run "cygrunsrv -I"?
But wouldn't I have to make sure that there are no other options that I
would need to set for "cygrunsrv" then?
-- 
View this message in context: 
http://old.nabble.com/Can-you-clone-entire-cygwin-setup-from-one-pc-to-another-tp26333733p26335899.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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 this message in context: 
http://old.nabble.com/Can-you-clone-entire-cygwin-setup-from-one-pc-to-another-tp26333733p26333860.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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). There might be one or 2 others I am missing.

Conceptually, it seems that it would be sufficient to just copy over the
C:\cygwin folder (plus my home directory) and to clone the registry entries.
One would be advised of course to use rsync with the -H flag to make sure
hard links are preserved.

But is there something I am missing?
Has anybody packaged up a script to copy over the registry entries? (that
would be the part I worry most since I wouldn't want to miss any entries or
corrupt anything) Are there any "hidden" persistent security entries?

I'm sure this has been addressed before but my googling only led to posts
about people trying to copy over the tar packages but I saw little about
cloning the full cygwin installation.

I want to do this since it could be a *lot* faster than first installing the
packages (that's not the problem) and then painstakingly redoing all my
customizations that accumulate over time.
--
View this message in context:
http://old.nabble.com/Can-you-clone-entire-cygwin-setup-from-one-pc-to-another-tp26333733p26333733.html
Sent from the Cygwin list mailing list archive at Nabble.com.

--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple

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

2009-11-12 Thread aputerguy


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 'cygwin' package is just about guaranteed to be in use if you are doing
anything cygwin related.

If you did the warning for this and maybe also bash (assuming it locks
files) then you would cover the key issues.
-- 
View this message in context: 
http://old.nabble.com/Suggestion%3A-Have-setup.exe-warn-before-upgrading-%27cgywin%27-package-itself-tp26327934p26328317.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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

2009-11-12 Thread aputerguy


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 processes
leaving you stuck in the middle of install while you wait to be able to
finish or kill the existing cygwin processes. Even worse, several core
cygwin utilities are now broken (such as 'ps') due to the partial install.

I have done this inadvertently a couple of times when 'cygwin' gets thrown
in as a part of another intentioned download.

Today I was left in an even odder state since I ran 'setup.exe' from a bash
prompt -- leaving me in a catch-22 since if I kill the bash processes then I
kill setup but I can't continue until I kill the bash processes...
-- 
View this message in context: 
http://old.nabble.com/Suggestion%3A-Have-setup.exe-warn-before-upgrading-%27cgywin%27-package-itself-tp26327934p26327934.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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-returns-0-if-no-file-found-tp26287360p26287360.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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 anymore as you expected in Windows.

Hmmm... even if I just turn it off for ordinary users?
I read through some of the Microsoft documentation and I didn't see any such
warning.


I guess I'm unsure of how to secure a machine easily and properly in Windows
in a way that is not just loaded with ACL's (you don't need to answer the
general question here since I will ask it more broadly in another thread)

>> While in Cygwin, for any value of  whether the file/directory
>> exists or not, I seem to get the following rather than an error message.
>> -rw-r--r-- 1 1006 513 0 Nov 30 2006 dir/
>> where 1006:513 = UID:GID

> Your own user account is in the administrators group, by any chance?

Mine is, but I was testing this in a bash.exe window that is 'runas' another
*non-administrator* user (belongs only to group Users)


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple




-- 
View this message in context: 
http://old.nabble.com/Differences-between-%27ls%27-permissions-*nix-vs-cygwin-tp26280017p26285839.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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 or is this a purposeful inconsistency?

-- 
View this message in context: 
http://old.nabble.com/Differences-between-%27ls%27-permissions-*nix-vs-cygwin-tp26280017p26285069.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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."

For example, if the current user doesn't have excutable (x) access to
'dir1', then in Linux:
$ls -nl dir1/
ls: cannot access dir1: Permission denied

While in Cygwin, for any value of  whether the file/directory
exists or not, I seem to get the following rather than an error message.
-rw-r--r-- 1 1006 513 0 Nov 30 2006 dir/
where 1006:513 = UID:GID

So, changing Bypass Traverse Checking has indeed now prevented me from
getting any "meaningful" file info but...
Why isn't cygwin ls returning an error message here?
Why isn't is consistent with *nix?
(note I started a new bash process, but I haven't rebooted after change
Bypass Traverse Checking)


-- 
View this message in context: 
http://old.nabble.com/Differences-between-%27ls%27-permissions-*nix-vs-cygwin-tp26280017p26284853.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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 Linux & Cygwin]

$ ls -d dir1/dir2
ls: cannot access directory dir1/dir2 Permission denied  [Linux]
dir1/dir2 [Cygwin]

No acl's beyond the standard ugo posix permissions are set on either system.
The Cygwin user only belongs to the 'None' and 'Users' group.

In particular, why is a non-privileged Cygwin user able to look over a
blocked directory further into a file tree?




-- 
View this message in context: 
http://old.nabble.com/Differences-between-%27ls%27-permissions-*nix-vs-cygwin-tp26280017p26280017.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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 cygwin. Just more of a
frustration of trying to merge the *nix and Windows worlds.

My problem is not within cygwin itself -- it's with trying to use cygwin to
also do Windoze-related tasks. In particular, I am trying to extend a
*nix-focused rsync-based program to do a better job of backing up Windoze
systems by capturing as much of the ntfs structure as possible. So, I am
trying to understand ACLs, reparse points, the MFT, etc.

Cygwin is of course awesome...
-- 
View this message in context: 
http://old.nabble.com/Finding-junction-points-in-cygwin-tp26260606p26279378.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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., Cygwin 1.x+, Windows ver X-Y, etc.)
C. Targets (e.g., files, directories, volumes)
D. Type of link/junction/mount point
E. *nix analogy and compatibility (including whether exact or similar)
F. Advantages relative to analogous concepts
G. Limitations, gotchas, etc.
H. How (or even if) handled by cygwin

-- 
View this message in context: 
http://old.nabble.com/Finding-junction-points-in-cygwin-tp26260606p26274197.html
Sent from the Cygwin list mailing list archive at Nabble.com.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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. Windows shortcuts
4. Junctions created by junction.exe
5. Reparse points created by linkd.exe
6. Other types of reparse points?
5. Mount points created by cygwin mount
6. Mount points created by mountvol
7. Letter drives created by dosdev
8. Letter drives created using Administrative Tools computer management
9. Other types of mounting?

I know that some of the above only work on files, some only on directories,
some only on shares, etc.
but there is a lot of overlap and a nice table would be very helpful.

Personally, I'm sure I don't understand all the differences, subtleties,
limitations, and when to use which one. I'm also left with the feeling that
Microsoft just keeps throwing new flavors of links and mounts rather than
going with a consistent approach but maybe I'm just biased to *nix.




-- 
View this message in context: 
http://old.nabble.com/Finding-junction-points-in-cygwin-tp26260606p26273453.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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 directory DOS attribute, it does
>not delete the symlink.

I'm sorry I meant linkd.exe.
It uses the '/D' flag to delete rather than *nix-like '-d'

-- 
View this message in context: 
http://old.nabble.com/Finding-junction-points-in-cygwin-tp26260606p26273434.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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 points created by linkd.exe
6. Other types of reparse points?
5. Mount points created by cygwin mount
6. Mount points created by mountvol
7. Letter drives created by dosdev
8. Letter drives created using Administrative Tools computer management
9. Other types of mounting?

I know that some of the above only work on files, some only on directories,
some only on shares, etc.
but there is a lot of overlap and a nice table would be very helpful.

Personally, I'm sure I don't understand all the differences, subtleties,
limitations, and when to use which one. I'm also left with the feeling that
Microsoft just keeps throwing new flavors of links and mounts rather than
going with a consistent approach but maybe I'm just biased to *nix.


-- 
View this message in context: 
http://old.nabble.com/Finding-junction-points-in-cygwin-tp26260606p26273372.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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'
flag rather than the dos-like '/D' flag that mklink seems to use.
-- 
View this message in context: 
http://old.nabble.com/Finding-junction-points-in-cygwin-tp26260606p26272231.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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. Something should be done here I think because otherwise you can
really unwittingly create a mess if someone else has created junctions and
you start renaming and moving files around. The behavior seems to be
unexpected and potentially destructive. Better to not allow any
(destructive) cygwin operations on such files than to have such unnatural
behavior.

I will look into getting mklink for XP in the meantime.
-- 
View this message in context: 
http://old.nabble.com/Finding-junction-points-in-cygwin-tp26260606p26272067.html
Sent from the Cygwin list mailing list archive at Nabble.com.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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 remaining question is can we assume that this bug (or bad coding) is
grep-specific or is it likely to rear its head in other core *nix utilities
that use UTF-8?
-- 
View this message in context: 
http://old.nabble.com/1.7--BUG---GREP-slows-to-a-crawl-with-large-number-of-matches-on-a-single-file-tp26224019p26271227.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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 on my machine... 

I found the problem once and then I reproduced it in order to cut & paste
the problem to the list.
But when I just tried to reproduce it again, I couldn't. So let's ignore
that problem for now or maybe it is related to whatever weirdness is causing
my Cygwin 1.7 not to recognize junctions as symlinks.

Any suggestions on how to troubleshoot why I'm not seeing the symlinks?

And just to confirm, 'find' also recognizes the junctions as files and
directories - not as symlinks.

-- 
View this message in context: 
http://old.nabble.com/Finding-junction-points-in-cygwin-tp26260606p26270902.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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 archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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

ls -Ag
drwxr-xr-x 1 None  0 2009-11-09 11:56 junctiondir/
-rw-r--r-- 1 None 20 2009-11-09 11:55 junctionfile
drwxr-xr-x 1 None  0 2009-11-09 11:56 targetdir/
-rw-r--r-- 1 None 20 2009-11-09 11:55 targetfile

mv junctionfile newjunctionfile
mv junctiondir newjunctiondir

ls -Ag 
drwxr-xr-x 1   0 2009-11-09 11:57 junctiondir/
drwxr-xr-x 1   0 2009-11-09 11:57 junctionfile/
drwxr-xr-x 1 None  0 2009-11-09 11:56 newjunctiondir/
-rw-r--r-- 1 None 20 2009-11-09 11:55 newjunctionfile

junction.exe -d junctionfile
junction.exe -d junctiondir

ls -Ag
drwxr-xr-x  1 None  0 2009-11-09 11:56 newjunctiondir/
-rw-r--r--  1 None 20 2009-11-09 11:55 newjunctionfile
drwx--+ 1 None  0 2009-11-09 12:01 targetdir/
drwx--+ 1 None  0 2009-11-09 12:01 targetfile/

Now this seems to be sheer madness.
The original file and directory names have reappeared!
However 'targetdir' is now empty and 'targetfile' is also an (empty)
directory!


ls -Ag targetdir targetfile newjunctiondir
newjunctiondir:
total 1
-rw-r--r-- 1 None 24 2009-11-09 11:56 targetdirfile

targetdir:
total 0

Interestingly, in Windows explorer, renaming seems to do the right thing -
it renames the target.

Interestingly, Windows explorer allows both file and directory junctions to
be removed (though it displays file junctions as non-openable directories).
Not sure why it does this since I thought junctions could only be deleted
using '-d'.

So it seems to me, we have the following conclusions:
- cygwin treatment of junctions is not consistent with Windows or with
notion of symlinks. It also leaves weird residua after renaming junctions.
- Windows junctions are also messed up but not as much




targetfile:
total 0




-- 
View this message in context: 
http://old.nabble.com/Finding-junction-points-in-cygwin-tp26260606p26270112.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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.exe to make a junction with a regular file, the
junction shows up as a regular file under cygwin. When I make a junction to
a directory, the junction shows up as a directory. In particular, I don't
see symlinks in either case.

2. Shouldn't we have a way of identify and/or differentiating junctions from
their targets. For example, cygwin (appropriately) doesn't allow you to
remove junctions using 'rm' (either files or directories). But if I am
writing code to manipulate files, I would like to be able to identify
junctions pro-actively rather than retroactively by the fact that I can't
remove them.

3. Moving a junction, moves the target file. And leaves the junction itself
'unlinked'. I'm not sure this is the logical behavior expected, particularly
if it is supposed to act like a symlink. Because with symlinks, 'mv' moves
the link not the target.

-- 
View this message in context: 
http://old.nabble.com/Finding-junction-points-in-cygwin-tp26260606p26269606.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Finding junction points in cygwin

2009-11-08 Thread aputerguy


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 delete junction points? (I know that
cygwin doesn't like them too much philosophically and they seem to be on
their way out anyway but...)


-- 
View this message in context: 
http://old.nabble.com/Finding-junction-points-in-cygwin-tp26260606p26260606.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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

2009-11-08 Thread aputerguy


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\)  \+\(user\|system\)  \+.*/\\1/p"
-- 
View this message in context: 
http://old.nabble.com/1.7--Can-you-have-multipe-cygdrive-path-prefixes-active-at-once-tp26227605p26260538.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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

2009-11-08 Thread aputerguy

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
stupidity" internal spaces are quite common in Windows (think 'Documents and
Settings', 'My Documents', 'Program Files', etc.) this would be a big and
potentially common miss.

I really think that mount should have a flag that lets you get the 'exact'
cygdrive rather than trying to parse some human readable version back into a
precise machine version.

More generally, it seems to go against the grain of the general *nix
philosophy to have a way of setting a parameter (in this case cygdrive
prefix) but not having a way to reliably read back that same prefix.

And regarding abject stupidity... *nix allows you to have some very weird
filenames (spaces, tabs, newlines, etc.) -- but there always seems to be a
reliable (though perhaps obscure) way to make sure you can recover or act on
the file name. Most importantly, in no case are you left with unresolvable
ambiguity.
-- 
View this message in context: 
http://old.nabble.com/1.7--Can-you-have-multipe-cygdrive-path-prefixes-active-at-once-tp26227605p26260476.html
Sent from the Cygwin list mailing list archive at Nabble.com.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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/Documents and Settings/Administrator/': Permission denied

I would have thought that 'ls' and 'find' would be bound by the same ACL
restrictions.

Am I missing something basic here in my understanding?
-- 
View this message in context: 
http://old.nabble.com/Why-do-%27find%27-and-%27ls%27-act-differently-on-ACLs-tp26250118p26250118.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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 North American English speaker, UTF-8 is not that important to me and
certainly not worth such a heavy overhead price.

Also, while I don't have 'pcgrep' installed on my machine, it is interesting
that 'sed' is not affected.
-- 
View this message in context: 
http://old.nabble.com/1.7--BUG---GREP-slows-to-a-crawl-with-large-number-of-matches-on-a-single-file-tp26224019p26249599.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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 dirname is used to effectively chop off the drive letter
> leaving you with the cygdrive prefix.

This doesn't seem to work in the case where you have mounted the C: drive.
For example I mount C: on /c

And the above returns:
$ dirname $(cygpath -u c:/)
/
which doesn't tell me what the cygdrive prefix is -- only where 'c' is
mounted.

Of course, as pointed out in a later reply, one can use an unused disk drive
letter like 'x' but that is hardly robust since who knows what drive letters
will be unused and/or unmounted.

-- 
View this message in context: 
http://old.nabble.com/1.7--Can-you-have-multipe-cygdrive-path-prefixes-active-at-once-tp26227605p26249511.html
Sent from the Cygwin list mailing list archive at Nabble.com.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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 someone
> intentionally uses trailing spaces in their cygdrive prefix, but I can
> understand the desire for robustness.

Yes - that was precisely my point. I am updating scripts that are used on an
open source project so I want them to be robust. If it were just for my own
use, I wouldn't even need to use "mount -p" since I know what *my* cygdrive
prefix is. But if you are writing general scripts, I think it is pretty
reasonable and basic to have a clear, easy, and robust way to know what the
root of the system is. As an analogy, imagine if in Linux root were not
always "/" and that there were no good way to robustly determine what your
particular value of root was -- certainly that would break (or at least
potentially break) many scripts.
-- 
View this message in context: 
http://old.nabble.com/1.7--Can-you-have-multipe-cygdrive-path-prefixes-active-at-once-tp26227605p26249482.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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 from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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 extract the prefix directly than to do some
bash grepping/cutting on the readable text output of mount -p?
I need to know the cygdrive prefix to make my scripts that call Windoze
executables work independent of what it might be set to.
-- 
View this message in context: 
http://old.nabble.com/1.7--Can-you-have-multipe-cygdrive-path-prefixes-active-at-once-tp26227605p26227605.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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 0m0.076s

While using sed on Cygwin 1.5, I get the reasonable result:
time sed -ne /dog/p testfile | wc

real0m1.229s
user0m1.202s
sys 0m0.046s


-- 
View this message in context: 
http://old.nabble.com/1.7--BUG---GREP-slows-to-a-crawl-with-large-number-of-matches-on-a-single-file-tp26224019p26226567.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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 something,
but I would like to correct for it.
Preferably correct it before it occurs rather than having to use some sed or
perl magic to clean up the file afterward.

Any suggestions?
-- 
View this message in context: 
http://old.nabble.com/Is-there-a-fast-way-to-get-acl%27s-for-the-whole-filesystem-%28or-chunk-thereof%29-tp26222793p26226546.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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 about half the 'system'
time.
-- 
View this message in context: 
http://old.nabble.com/Is-there-a-fast-way-to-get-acl%27s-for-the-whole-filesystem-%28or-chunk-thereof%29-tp26222793p26226433.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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 plain text file of the acl's of all the 108,000
files on my Windoze computer.

Note since the machines are different, compare relative times across cases
rather than the times between the two machines.

Case 1] Zero matches
time grep "sfsdfdsfds" testfile | wc
 0   0   0

Cygwin 1.5
real0m0.093s
user0m0.092s
sys 0m0.030s

Cygwin 1.7
real0m1.353s
user0m1.342s
sys 0m0.062s

Case 2] One match
time grep ".lesshst" testfile | wc
  1   3  29

Cygwin 1.5 (~same as zero matches)
real0m0.234s
user0m0.091s
sys 0m0.061s

Cygwin 1.7 (~same as zero matches)
real0m1.499s
user0m1.404s
sys 0m0.046s

Case 3] ~1400 matches

Cygwin 1.5 (~ same as zero matches)
time grep ".bin" testfile | wc
   14395661   71067

real0m0.110s
user0m0.076s
sys 0m0.077s

Cygwin 1.7 (~6x zero matches case
real0m7.537s
user0m7.341s
sys 0m0.045s

Case 4] ~16000 matches
time grep "Documents and Settings" testfile | wc
  15824  131573 1918500

Cygwin 1.5 (~same as zero matches)
real0m0.437s
user0m0.092s
sys 0m0.092s

Cygwin 1.7 (~50x zero matches)
real1m14.491s
user1m8.904s
sys 0m0.031s


Case 5] ~100,000 matches
time grep "# file" testfile | wc
 106988  510944 7930558

Cygwin 1.5 (~1.5x zero matches)

real0m0.475s
user0m0.154s
sys 0m0.201s

Cygwin 1.7 (~350x zero matches)
real7m51.771s
user7m16.810s
sys 0m0.062s

Case 6] Test that nothing wrong with file system reads or 'wc'
time cat testfile | wc
 966300 1821815 20426592

Cygwin 1.5 (approx same time as grepping zero matches)
real0m0.344s
user0m0.201s
sys 0m0.186s

Cygwin 1.7 (approx same time as grepping zero matches)
real0m1.662s
user0m1.373s
sys 0m0.138s



-- 
View this message in context: 
http://old.nabble.com/1.7--BUG---GREP-slows-to-a-crawl-with-large-number-of-matches-on-a-single-file-tp26224019p26224019.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

[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
get USERNAME=SYSTEM (assuming that you started sshd normally with
cygrunsrv).

I use 'ssh' to log on to remote computers to initialize backups by setting
up shadow mounts. However, since vshadow won't run as user SYSTEM, I have to
go through crazy hoops using 'at' to launch the process at the next minute
in the future so that I can get vshadow to run.

This ssh/security limitation is odd coming from a *nix environment where ssh
gives you all the power you want or need...
-- 
View this message in context: 
http://old.nabble.com/-1.7--Do-the-new-security-enhancements-allow-ssh-under-your-own-%24USERNAME-tp26223586p26223586.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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 there a faster way to do this (hopefully without having to go write
C-code)?
-- 
View this message in context: 
http://old.nabble.com/Is-there-a-fast-way-to-get-acl%27s-for-the-whole-filesystem-%28or-chunk-thereof%29-tp26222793p26222793.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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 workaround.  Use your
> own tool as below.
> 
> The only hack that I have found to get around this is to use an *old*,
> *unsupported* Microsoft routine called 'dosdev' which allows you to
> assign drive letters to devices, including using the GLOBALROOT
> format.
>
>Try this:
>
> $ cat > DefDosDevice.c << EOF

Cool
Two follow-up questions:
1. Any idea how this differs from dosdev.exe? Is it faster/slower? More/less
robust? More/less portable?
2. Should this short routine be added somewhere in the cygwin distribution?
It seems incredibly useful and simple.
-- 
View this message in context: 
http://old.nabble.com/Accessing-GLOBALROOT-paths---a-potential-compromisetp26175496p26222690.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

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