Re: all files seems to be owned by the actual user

[Matthias Meyer]

Brian Dessent wrote:

> Matthias Meyer wrote:
> 
>> Another strangely effect is that "ls -alnh /" lists all files as owned by
>> the actual user.
>> If I do that as another user the files will also be listet as owned by
>> him, the user who runs the ls.
>> 
>> What is the reason for that?
> 
> You instructed Cygwin to not read or write any ACLs by setting nontsec.
> It has to fill in those fields with something so it just lists whatever
> the current user is as the owner (just as it would have had to do with a
> filesystem like FAT or an OS like Win95 that doesn't record an owner.)
> 
>> Is there a possibility to backup the files from different users (e.g.
>> with rsync) and restore them with the same owner and permissions which
>> they have at backup time?
> 
> Certainly not with nontsec in effect.
> 
> Brian
Thanks,
I've tried also ntsec, binmode and "".
All of this three list the true file owner with "ls -anlh".
But as before, rsync -a create the files with the user who runs the rsync
command. Also rsync -aA with or without --numeric-ids have this behaviour.

I would believe that I have a very stupid failure. I can not believe that it
is not possible to backup and restore the file owner.

-- 
Don't panic


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

gdb is sooooo slow - is that normal?

[John Emmas]

I use an IDE called CodeBlocks to build and debug my Cygwin projects.  The
builds usually go okay but debugging is horrendously slow.  CodeBlocks has
a debugger output window which typically shows output like this (I assume
this is either what's being sent to gdb or what's getting returned) -

This GDB was configured as "i686-pc-cygwin".

cb_gdb:

set confirm off

cb_gdb:

set width 0

cb_gdb:

set height 0

cb_gdb:

set breakpoint pending on

cb_gdb:

set print asm-demangle on


That shows 5 stages out of maybe 20 or so that seem to run before my own app
appears on screen.  The problem is that each of those stages can take
anywhere from about 6 seconds up to 15 seconds (taking longer, the more
breakpoints I've set).  Therefore after starting the debug process, it can
take between 2 minutes and maybe 6 minutes before my app gets launched.  Is
this normal for Cygwin?  The more complex the app, the worse the problem is.
If I set more than about 5 breakpoints with a complicated app, the debugger
takes so long to get going that it becomes not worth waiting.  Does anyone
else find this?  I'd like to find out whether it's a problem with Cygwin or
with CodeBlocks.

Thanks,

John


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

Re: all files seems to be owned by the actual user

[Brian Dessent]

Matthias Meyer wrote:

> I've tried also ntsec, binmode and "".

Why are you doing these things?  Are you following somebody's "guide"? 
Please tell them that they are spreading useless information if that is
the case.  ntsec is the default.  binmode is the default and is
irrelevant for files anyway.  So "" is the same as "ntsec binmode", and
you should not need to set CYGWIN at all in general unless there is a
*specific* reason that calls for it.

> All of this three list the true file owner with "ls -anlh".
> But as before, rsync -a create the files with the user who runs the rsync
> command. Also rsync -aA with or without --numeric-ids have this behaviour.
> 
> I would believe that I have a very stupid failure. I can not believe that it
> is not possible to backup and restore the file owner.

rsync only tries to set the owner when it thinks it has the privilege to
do so -- on most POSIX systems this means being the superuser, uid=0. 
This check in rsync is less than useful on Cygwin where privileges work
differently.  Thankfully they provide an override in the form of the
--super switch.

Brian

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

Re: gdb is sooooo slow - is that normal?

[Brian Dessent]

John Emmas wrote:

> That shows 5 stages out of maybe 20 or so that seem to run before my own app
> appears on screen.  The problem is that each of those stages can take
> anywhere from about 6 seconds up to 15 seconds (taking longer, the more
> breakpoints I've set).  Therefore after starting the debug process, it can
> take between 2 minutes and maybe 6 minutes before my app gets launched.  Is
> this normal for Cygwin?  The more complex the app, the worse the problem is.
> If I set more than about 5 breakpoints with a complicated app, the debugger
> takes so long to get going that it becomes not worth waiting.  Does anyone
> else find this?  I'd like to find out whether it's a problem with Cygwin or
> with CodeBlocks.

No, that's certainly not normal.  Try the same commands directly in
Cygwin's packaged gdb with CodeBlocks completely removed from the
picture and see if it's the same speed.

Brian

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

[ANNOUNCEMENT] Updated: opengl-1.1.0-10

[André Bleau]

 
Version 1.1.0-10 of the opengl package has been released.
 
This package contains OpenGL-related libraries: GLUT, GLUI, and GLUIX 
librairies 
to develop portable OpenGL programs that do not require an X server to run. 
These programs can display through the native Windows interface (Win32) 
and benefit from hardware and driver acceleration.
 
This update should solve the problems about a missing .lib file, such as:
 
http://cygwin.com/ml/cygwin-xfree/2008-12/msg00030.html
 
The previous conflict with the w32api package over the libglut32.a file 
has been solved by the latest w32api package update, thanks to Chris Sutcliffe.
See: http://cygwin.com/ml/cygwin-apps/2008-12/msg00027.html
 
You must update to w32api-3.13-1 to update to opengl-1.1.0-10 . Automatic
dependency checking in the setup program should take care of that.
 
Unfortunately, users of the opengl package might have to change the way they 
build their applications. More specificaly, compiling with 
-I/usr/include/opengl 
is REQUIRED when the libGL-devel, libGLU-devel, libglut-devel packages are also 
installed. See:
 
http://cygwin.com/ml/cygwin/2008-11/msg00056.html
 
Exerbs from the updated README.txt:
 
>---<
 
What has changed since opengl-1.1.0-9
-
 
The usr/lib/w32api/glut32.lib that was supposed to be provided was in fact
missing. The conflict over usr/lib/w32api/libglut32.a with the w32api package
has been resolved; that file is now part of the opengl package.
 

What has changed since opengl-1.1.0-8
-
 
A new symbolic link, /usr/include/opengl/GL -> /usr/include/w32api/GL was
added to be able to compile native OpenGL, GLU, GLUT, GLUI, and GLUIX program 
when the libGL-devel, libGLU-devel, libglut-devel packages are also installed. 
In that case, compiling with -I/usr/include/opengl is REQUIRED, 
otherwise the headers from libGL-devel, libGLU-devel, libglut-devel will be 
used, leading to missing functions at link time. If the libGL-devel, 
libGLU-devel, libglut-devel package are not installed, 
you can compile as usual.
 
A bug introduced in opengl-1.1.0-6 was corrected in glut.h. The bug caused the
program to continue to run in the background if its window was closed by using
the close (X) icon in the title bar. If you prefer to keep that behavior, you 
must recompile with -DGLUT_DISABLE_ATEXIT_HACK .
 
glut-examples was added to /usr/lib.
 
The helloGLUT example program was improved.
 
FAQ.txt was added.
 
>---<
 
Enjoy,
 
- André Bleau, Cygwin's volunteer OpenGL package maintainer.
 
Please direct any question or comment about the OpenGL package to cygwin at 
cygwin dot com
 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***
 
If you want to unsubscribe from the cygwin-announce mailing list, look at the 
"List-Unsubscribe: " tag in the email header of this message. Send email to 
the address specified there. It will be in the format:
 
[EMAIL PROTECTED]
 
If you need more information on unsubscribing, start reading here:
 
http://sourceware.org/lists.html#unsubscribe-simple
 
Please read *all* of the information on unsubscribing that is available 
starting 
at this URL. 
 
_


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

Re: all files seems to be owned by the actual user

[Matthias Meyer]

Brian Dessent wrote:

> Matthias Meyer wrote:
> 
>> I've tried also ntsec, binmode and "".
> 
> Why are you doing these things?  Are you following somebody's "guide"?
> Please tell them that they are spreading useless information if that is
> the case.  ntsec is the default.  binmode is the default and is
> irrelevant for files anyway.  So "" is the same as "ntsec binmode", and
> you should not need to set CYGWIN at all in general unless there is a
> *specific* reason that calls for it.
> 
>> All of this three list the true file owner with "ls -anlh".
>> But as before, rsync -a create the files with the user who runs the rsync
>> command. Also rsync -aA with or without --numeric-ids have this
>> behaviour.
>> 
>> I would believe that I have a very stupid failure. I can not believe that
>> it is not possible to backup and restore the file owner.
> 
> rsync only tries to set the owner when it thinks it has the privilege to
> do so -- on most POSIX systems this means being the superuser, uid=0.
> This check in rsync is less than useful on Cygwin where privileges work
> differently.  Thankfully they provide an override in the form of the
> --super switch.
> 
> Brian

Thanks Brian,
Maybee I am a little bit helpless ;-)
Please can you say what I have to do?
Should rsync -a --super /cygdrive/c/data /cygdrive/c/backup do the job what
I want?

Is there a possibility to backup the files from different users (e.g. with
rsync) and restore them with the same owner and permissions which they have
at backup time?

Thanks in advance
Matthias
-- 
Don't panic


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

RE: RSync random failures

[Matthias Meyer]

Allan Schrum wrote:
> 
> Hi Matthias,
> 
> The problem is when rsync is not actively connected to a client. When
> started as a service, an instance of rsync is running listening for
> connections. When the connection occurs, the transfer takes place.
> Afterwards, the original instance remains still listening for connections.
> When running as a service waiting for a connection, something happens to
> it which causes it to fail and exit without cleaning up. This leaves a PID
> file which blocks all restart attempts. I then must manually clean up the
> PID file to allow the service to restart. Obviously, leaving the PID file
> should not take place which is the symptom of the true problem.
> 
> Something is causing rsync to fail without cleaning up the PID file.
> Sometimes it is a reboot (most often due to that). Sometimes during a
> transfer it will fail and not cleanup properly. I have not yet figured
> this out and was hoping others saw this as well.
> 
> I did notice that while debugging (with gdb) rsync that if I type Ctrl-C
> that the task stops without cleaning up. However, I'm not sure if that is
> due to how gdb works, or something else.
> 
> Again, this is with rsync-3.0.4-1. This cleanup problem did not exist with
> rsync-2.6.9-2. As a temporary solution, I am back to the older rsync on
> most of my machines until we get this current problem resolved.
> 
> Thanks,
> 
> -Allan

Hi Allen,

I didn't understand your problem.
You didn't need this PID file. Simply remove the line
pid file = 
from your rsyncd.conf

br
Matthias
-- 
Don't panic


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

Re: all files seems to be owned by the actual user

[Brian Dessent]

Matthias Meyer wrote:

> Please can you say what I have to do?
> Should rsync -a --super /cygdrive/c/data /cygdrive/c/backup do the job what
> I want?

Yes, that ought to work.  Does it?

Brian

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

rsync restore the file owner but rsyncd do it not

[Matthias Meyer]

Hi all,

I want use rsync to backup a windows XP professional client to my linux server.
I've installed cygwin/rsync on windows and start with a local windows backup.

rsync -aA --super /cygdrive/c/bootfont.bin /cygdrive/c/backup
copies the file, but only the attributes "RA" and not "the original "RHSA".
rsync -aA --super /cygdrive/c/backup/bootfont.bin /cygdrive/c/data
restore the file as it was backed up. With the attributes "RA"

My first questions:
What the reason for not copying the attributes "HS"?
If I try "-X" I get an error "rsync: extended attributes are not supported on 
this client"

Than I install rsync as a windows service:
cygrunsrv -I rsyncd -e -n -t auto -p /bin/rsync -a "--daemon --no-detach 
--config=/etc/rsyncd.conf"
cygrunsrv -S rsyncd

...and try a local backup:
rsync -aA --super localhost::BACKUP/bootfont.bin /cygdrive/c/backup
copies the file, but also only the attributes "RA" and not "the original "RHSA".
and the appropriate restore:
rsync -aA --super /cygdrive/c/backup/bootfont.bin localhost::BACKUP
rsync: chown ".bootfont.bin.KYyS5D" (in BACKUP) failed: Invalid argument (22)

and the file will be restored with the owner of the rsyncd process:
ls -al shows - SYSTEM 
ls -an shows - 18 4294967295

bootfont.bin is originaly owned by:
ls -al shows - Administratoren  (german XP ;-))
ls -an shows - 544 4294967295

The same behavior occurs with a file test.txt which is owned by:
ls -al shows - user mkgroup
ls -an shows - 1006 513

What is going wrong?
Thanks
Matthias
-- 
Don't panic


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

Re: rsync restore the file owner but rsyncd do it not

[Brian Dessent]

Matthias Meyer wrote:

> My first questions:
> What the reason for not copying the attributes "HS"?

rsync is a POSIX program.  It sees everything in terms of POSIX.  That
means it sees a file mode, such as 0644, 0755, etc.  It reads a mode on
the source and sets that same mode on the dest, that is it.  It has no
idea what H/S/R/A attributes mean or that they even exist.

The A attribute gets set on the dest file simply because that is the
default behavior when creating a file.  The R attribute gets set because
Cygwin can map that bit easily onto the POSIX "u=w" mode bit, such that
setting a mode like 0444 will cause R to be set and setting 0644 will
cause R to be reset.  But S and H have no such easy mapping onto POSIX
modes, so they aren't propagated.

> If I try "-X" I get an error "rsync: extended attributes are not supported on 
> this client"

Any EA support in rsync would most likely be some form of POSIX EA
anyway, not R/H/S/A, so I don't think this really matters.

> The same behavior occurs with a file test.txt which is owned by:
> ls -al shows - user mkgroup
> ls -an shows - 1006 513



Brian

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

Re: rsync restore the file owner but rsyncd do it not

[Matthias Meyer]

Brian Dessent wrote:

> Matthias Meyer wrote:
> 
>> My first questions:
>> What the reason for not copying the attributes "HS"?
> 
> rsync is a POSIX program.  It sees everything in terms of POSIX.  That
> means it sees a file mode, such as 0644, 0755, etc.  It reads a mode on
> the source and sets that same mode on the dest, that is it.  It has no
> idea what H/S/R/A attributes mean or that they even exist.
> 
> The A attribute gets set on the dest file simply because that is the
> default behavior when creating a file.  The R attribute gets set because
> Cygwin can map that bit easily onto the POSIX "u=w" mode bit, such that
> setting a mode like 0444 will cause R to be set and setting 0644 will
> cause R to be reset.  But S and H have no such easy mapping onto POSIX
> modes, so they aren't propagated.
> 
>> If I try "-X" I get an error "rsync: extended attributes are not
>> supported on this client"
> 
> Any EA support in rsync would most likely be some form of POSIX EA
> anyway, not R/H/S/A, so I don't think this really matters.
> 
>> The same behavior occurs with a file test.txt which is owned by:
>> ls -al shows - user mkgroup
>> ls -an shows - 1006 513
> 
> 
> 
> Brian

Thanks Brian!

It seems I had run "bin\mkgroup -l > etc\passwd" instead "bin\mkgroup -l >
etc\group".
Now it works.
It seems that rsync (or cygwin) set the process-owner as file-owner if it
can not find the uid/gid within /etc/passwd and /etc/group.

Now I will try the game from windows client to linux server and return.

br
Matthias
-- 
Don't panic


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

Problems with remote programs using ncurses (aptitude)

[SO]

Hello,

I have problems opening remote programs using ncurses library.
Aptitude for example. Menus and other interface components are just
garbage on my term on windows vista. Is there a solution for that?

Thanks.

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