Re: rsync problems from Vista installed cygwin, ok on XP

[DaveB]

Igor Peshansky wrote:
> 
> On Mon, 20 Aug 2007, DaveB wrote:
> 
>> Corinna Vinschen-2 wrote:
>> >
>> > On Aug 18 21:06, DaveB wrote:
>> >> So... two interesting followon points...
>> >>
>> >> 1. Why didn't the ACLs get set to something reasonable as opposed to
>> >> 000 in the first place when I created this little test area in Vista?
>> >> After all, I
>> >
>> > The directory has been created using native Windows tools.  The
>> > permissions given using native Windows tools *are* strange and don't
>> > follow POSIX rules. It's perfectly valid that you can access a
>> > directory under Windows but get 000 POSIX permissions.  You did see
>> > the '+' at the end of the permission in ls -l?
>>
>> OK, I now see this + and had no idea what it meant... but have now found
>> the doc in cygwin by typing "info ls", where it says...
>>
>>  Following the file mode bits is a single character that specifies
>>  whether an alternate access method such as an access control list
>>  applies to the file.  When the character following the file mode
>>  bits is a space, there is no alternate access method.  When it is
>>  a printing character, then there is such a method.
>>
>>  For a file with an extended access control list, a `+' character is
>>  listed.  Basic access control lists are equivalent to the
>>  permissions listed, and are not considered an alternate access
>>  method.
>>
>> Interesting.  So if it knows there is an ACL which overrides the --
>> permissions that were inherited from C:\ then why can't the cygwin port
>> of rsync allow a Windows-friendly option for rsync'ing these files...
>> even if it cannot directly read the ACL maybe it could allow you to
>> invoke some special rsync permissions sync'ing flag?
>>
>> I looked in the man rsync doc, and found some flags that might be
>> helpful ... namely -p -E and --chmod.  But even chmod=XXX doesn't quite
>> let you do automatically what would make sense, which is to create
>> rsync'd files with rwx for the exe's and rw for the others.
>>
>> Not sure what the best way out of here is...??? I'm beginning to
>> understand this a bit better, but it sure is a minefield... will
>> generate ongoing problems for innocent future users.
> 
> You misunderstand your problem.  The problem is not that rsync on the
> source side cannot read the files (it can, since the ACLs allow it to).
> The problem is that the rsync on the destination side copies only the Unix
> permission bits from the source side (which are 000), and then it is
> unable to write to that directory (because the permissions are 000).
> 
> What you want is some way of getting rsync to not copy permissions, or
> making rsync ACL-aware.  I don't know of any way to do either, but then, I
> haven't used rsync extensively.  Perhaps the documentation holds the
> answer.
> 
>> PS Can anyone point to a good article on ACL that explains the
>> relationship to these ls -l permissions also?
> 
> I'm sure MSDN has a lot of info on ACLs in general and on their use in
> Windows.  If you want to know specifically how Cygwin maps ACLs to Unix
> permission bits, see .
>   Igor
> 

Don't think I misunderstood... what I was saying above agrees with you - the
ACLs allow cygwin/rsync to read the files, but it then proceeds to transfer
the posix permissions, which are 000.
The ntsec article above is very helpful actually, explaining the problem
more clearly - there is a mismatch between posix and NT security. cygwin is
an environment trying to bridge the gap.

It seems that a good solution might be to provide a cygwin environment
variable which "OR"s the read/write access of the current user with the
posix flags right from the start... Then even an ls -l would come up with
rwx where applicable (instead of --- at the moment), and programs like
cygwin/rsync would then behave themselves and cause less of a surprise to
the end user.

My earlier comment said
>why can't the cygwin port of rsync allow a Windows-friendly option for
rsync'ing these files
If there was a Windows friendly env variable that made current ACL the
default reported security setting for the rwx flag (at least for the owner)
then there would be no need to fiddle with anything in rsync, fix the
problem upstream.  Cygwin does things like this in other areas - eg it
provides env variables for dealing better with the case dependence in
filenames which is fundamentally different between unix and Windows.  So why
not make it behave more like Windows in the security area?  Until it was
pointed out to me what was going on here, I was oblivious to the --- posix
setting and happily reading and writing files in this directory in Windows,
so of course it was a surprise when rsync's copy of the directory to a unix
system zapped the rwx setting of the directory copy up there.  As Igor is
saying, this is the underlying problem...

>The problem is not that rsync on the
>source side cannot re

Re: rsync problems from Vista installed cygwin, ok on XP

[Igor Peshansky]

On Mon, 20 Aug 2007, DaveB wrote:

> Corinna Vinschen-2 wrote:
> >
> > On Aug 18 21:06, DaveB wrote:
> >> So... two interesting followon points...
> >>
> >> 1. Why didn't the ACLs get set to something reasonable as opposed to
> >> 000 in the first place when I created this little test area in Vista?
> >> After all, I
> >
> > The directory has been created using native Windows tools.  The
> > permissions given using native Windows tools *are* strange and don't
> > follow POSIX rules. It's perfectly valid that you can access a
> > directory under Windows but get 000 POSIX permissions.  You did see
> > the '+' at the end of the permission in ls -l?
>
> OK, I now see this + and had no idea what it meant... but have now found
> the doc in cygwin by typing "info ls", where it says...
>
>  Following the file mode bits is a single character that specifies
>  whether an alternate access method such as an access control list
>  applies to the file.  When the character following the file mode
>  bits is a space, there is no alternate access method.  When it is
>  a printing character, then there is such a method.
>
>  For a file with an extended access control list, a `+' character is
>  listed.  Basic access control lists are equivalent to the
>  permissions listed, and are not considered an alternate access
>  method.
>
> Interesting.  So if it knows there is an ACL which overrides the --
> permissions that were inherited from C:\ then why can't the cygwin port
> of rsync allow a Windows-friendly option for rsync'ing these files...
> even if it cannot directly read the ACL maybe it could allow you to
> invoke some special rsync permissions sync'ing flag?
>
> I looked in the man rsync doc, and found some flags that might be
> helpful ... namely -p -E and --chmod.  But even chmod=XXX doesn't quite
> let you do automatically what would make sense, which is to create
> rsync'd files with rwx for the exe's and rw for the others.
>
> Not sure what the best way out of here is...??? I'm beginning to
> understand this a bit better, but it sure is a minefield... will
> generate ongoing problems for innocent future users.

You misunderstand your problem.  The problem is not that rsync on the
source side cannot read the files (it can, since the ACLs allow it to).
The problem is that the rsync on the destination side copies only the Unix
permission bits from the source side (which are 000), and then it is
unable to write to that directory (because the permissions are 000).

What you want is some way of getting rsync to not copy permissions, or
making rsync ACL-aware.  I don't know of any way to do either, but then, I
haven't used rsync extensively.  Perhaps the documentation holds the
answer.

> PS Can anyone point to a good article on ACL that explains the
> relationship to these ls -l permissions also?

I'm sure MSDN has a lot of info on ACLs in general and on their use in
Windows.  If you want to know specifically how Cygwin maps ACLs to Unix
permission bits, see .
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Belief can be manipulated.  Only knowledge is dangerous.  -- Frank Herbert

--
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 problems from Vista installed cygwin, ok on XP

[DaveB]

Corinna Vinschen-2 wrote:
> 
> On Aug 18 21:06, DaveB wrote:
>> So... two interesting followon points...
>> 
>> 1. Why didn't the ACLs get set to something reasonable as opposed to 000
>> in
>> the first place when I created this little test area in Vista?  After
>> all, I
> 
> The directory has been created using native Windows tools.  The
> permissions
> given using native Windows tools *are* strange and don't follow POSIX
> rules.
> It's perfectly valid that you can access a directory under Windows but get
> 000 POSIX permissions.  You did see the '+' at the end of the permission
> in ls -l?
> 

OK, I now see this + and had no idea what it meant... but have now found the
doc in cygwin by typing "info ls", where it says...

 Following the file mode bits is a single character that specifies
 whether an alternate access method such as an access control list
 applies to the file.  When the character following the file mode
 bits is a space, there is no alternate access method.  When it is
 a printing character, then there is such a method.

 For a file with an extended access control list, a `+' character is
 listed.  Basic access control lists are equivalent to the
 permissions listed, and are not considered an alternate access
 method.

Interesting.  So if it knows there is an ACL which overrides the --
permissions that were inherited from C:\ then why can't the cygwin port of
rsync allow a Windows-friendly option for rsync'ing these files... even if
it cannot directly read the ACL maybe it could allow you to invoke some
special rsync permissions sync'ing flag?

I looked in the man rsync doc, and found some flags that might be helpful
... namely  -p -E and --chmod.  But even chmod=XXX doesn't quite let you do
automatically what would make sense, which is to create rsync'd files with
rwx for the exe's and rw for the others.

Not sure what the best way out of here is...??? I'm beginning to understand
this a bit better, but it sure is a minefield... will generate ongoing
problems for innocent future users.

PS Can anyone point to a good article on ACL that explains the relationship
to these ls -l permissions also?


-- 
View this message in context: 
http://www.nabble.com/rsync-problems-from-Vista-installed-cygwin%2C-ok-on-XP-tf4260918.html#a12232786
Sent from the Cygwin Users mailing list archive at Nabble.com.


--
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 problems from Vista installed cygwin, ok on XP

[Corinna Vinschen]

On Aug 18 21:06, DaveB wrote:
> So... two interesting followon points...
> 
> 1. Why didn't the ACLs get set to something reasonable as opposed to 000 in
> the first place when I created this little test area in Vista?  After all, I

The directory has been created using native Windows tools.  The permissions
given using native Windows tools *are* strange and don't follow POSIX rules.
It's perfectly valid that you can access a directory under Windows but get
000 POSIX permissions.  You did see the '+' at the end of the permission
in ls -l?


Corinna

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

--
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 problems from Vista installed cygwin, ok on XP

[DaveB]

Igor Peshansky wrote:
> 
> 
>> DaveB wrote[snip]
>> Local permissions...  haven't used getfacl before but tried it in cygwin
>> and got this...
>>
>> 
>> [EMAIL PROTECTED] /cygdrive/c/4up
>> $ getfacl *
>> # file: 20070709 mach refresh issue
>> # owner: daveb
>> # group: None
>> user::---
>> group::---
>> group:SYSTEM:rwx
>> group:Administrators:rwx
>> group:Users:r-x
>> mask:rwx
>> other:---
>> default:group:SYSTEM:rwx
>> default:group:Administrators:rwx
>> default:group:Users:r-x
>> default:mask:rwx
>>
>> # file: somejunk.txt
>> # owner: daveb
>> # group: None
>> user::---
>> group::---
>> group:SYSTEM:rwx
>> group:Administrators:rwx
>> group:Users:r-x
>> mask:rwx
>> other:---
>>
>> =
>>
>> Vista account is only one on machine, has admin privileges.
>> UAC is switched on.
>> I did have cygwin, hence rsync running normally in this test, but now
>> that
>> you remind me, I also tried it before using "Run As Administrator" on
>> cygwin. Made no difference.
>> ...[snip]
> 
> Ok, here's a WAG.  Your problem stems from the fact that the Unix
> permissions on that directory really are 0.  All of the access information
> is stored in separate ACLs, which rsync does not copy.  Thus, it sets the
> permissions on the remote copy to 0, and, obviously, is unable to write to
> that directory afterwards.
> 
> You can run "chmod -R 775" on that directory, which should, if my WAG
> above is correct, fix your rsync problem.
>   Igor
> P.S. Before you ask, I'm not aware of any way to make rsync copy the ACLs.
> 

Hey that did it!!! Thanks!!!  In cygwin I did an ls -laR and confirmed the
directory had d-- privileges. The first attempt to chmod -R 775 failed,
then I restarted cygwin with "Run As Administrator" and it worked.  The
first attempt to rsync then failed because the folder up there on the Linux
machine was still set to d-- from the last attempt... so I went in and
chmod'd that to 755 (not 775, deliberately different)... then tried the
rsync again... hummed along no problems, then after completion I went back
to the Linux machine and the test files were all there and the privileges
for the folder had been changed from 755 to 775 (drwxrwxr-x)... perfect.

So... two interesting followon points...

1. Why didn't the ACLs get set to something reasonable as opposed to 000 in
the first place when I created this little test area in Vista?  After all, I
could do directory listings even in cygwin, so it seems a bit of an unfair
trick on me that the access was actually set to 000...  In fact, thinking
about it, I guess it inherited the 000 from the parent c:\ directory.  But
just seems a bit odd to me that I ended up with this 000 setting which in
unix systems means one cannot even do an ls yet I was totally unaware of it
and able to see all the files

2. Given the above, and Igor's comments that rsync will not copy ACLs, why
in the world did rsync copy the strange 000 flags... hmmm... not sure about
this, in a way it is 100% correct to do that, but maybe there should be
(maybe there already is??) a flag on rsync which stops it setting
permissions during the transfers.

Having made these observations, I must say that in my case the problem is
now 100% solved by Igor's suggestion... I will simply do that chmod 775 -R
to all my file trees I intend to sync in future.  But this sure is a trap
for the innocent...  thanks again Igor
-- 
View this message in context: 
http://www.nabble.com/rsync-problems-from-Vista-installed-cygwin%2C-ok-on-XP-tf4260918.html#a12219269
Sent from the Cygwin Users mailing list archive at Nabble.com.


--
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 problems from Vista installed cygwin, ok on XP

[Igor Peshansky]

On Fri, 17 Aug 2007, DaveB wrote:

> Corinna Vinschen-2 wrote:
> >
> > For testing I copied over the whole /usr directory from my Vista box
> > to a Linux machine.  I'm rather puzzled how setting permissions on the
> > *remote* machine should be affected by the OS of the source machine.
> >
> > I guess we need much more information.  Are the affected directories
> > Cygwin-created directories or natively created dirs?  Do they contain
> > spaces or native characters?  What are the local permissions on them
> > (getfacl/cacls)?  Does your Vista account have admin privileges?  UAC
> > switched on?  If so, is rsync running normally with reduced privileges
> > or "as administrator"?  Is your remote Unix account root or non-root?
> >
> > Corinna
>
> OK, encouraged by hearing that it works for you from Vista to a Linux
> machine, I have retraced my steps and tried a much simpler contrived
> example.  I set up a little folder tree c:\4up with a single file called
> somejunk.txt and one subfolder with two files, a txt and a jpg, latter
> with spaces but certainly no special characters.  That's on the Vista
> pc.  Then I putty'd across to my ftp area on a Linux server and created
> a new subfolder there called .../4up to copy these files to via rsync.
> ls shows total 0 in putty.
> Then back on Vista pc in cygwin I cd'd to the 4up folder and typed in
> this dry run rsync command
>
> $ rsync -avzn --stats --progress -e ssh . [EMAIL PROTECTED]:/home/xxx/yyy/4up
>
> It happily responded, listing the 2 directories and 3 files and no
> errors. I then repeated the command without the dry run -n flag... ie
> set it live. It came up with all the errors as before...
>
> ==
> $ rsync -avz --stats --progress -e ssh . [EMAIL PROTECTED]:/home/xxx/yyy/4up
>
> [EMAIL PROTECTED]'s password:
> building file list ...
> 5 files to consider
> ./
> rsync: failed to modify permissions on "/home/xxx/yyy/4up/.": Permission
> denied (13)
> rsync: recv_generator: failed to stat "/home/xxx/yyy/4up/somejunk.txt":
> Permission denied (13)
> 20070709 mach refresh issue/
> rsync: recv_generator: mkdir "/home/xxx/yyy/4up/20070709 mach refresh issue"
> failed: Permission denied (13)
> *** Skipping everything below this failed directory ***
> rsync: failed to modify permissions on "/home/xxx/yyy/4up/20070709 mach
> refresh issue": Permission denied (13)
> rsync: recv_generator: mkdir "/home/xxx/yyy/4up/." failed: Permission denied
> (13)
> *** Skipping everything below this failed directory ***
>
> etc...
> ===
>
> and after doing this failed rsync, I went back to the putty window to
> look at the remote machine and typed ls again... and bingo... permission
> denied. cd .. and ls -l shows the directory 4up with permission now set
> to 0:
> d-   2  x   48 Aug 17 07:42 4up/
>
> ===
>
> Let me answer the rest of the questions if I can.
> The affected directories are not cygwin created, now or before.  They
> are natively created.
> They do not contain special chars, nor does the full path to the first
> file even contain a space c:\4up\somjunk.txt but the subfolder and the
> two files in it contain spaces.
> Local permissions...  haven't used getfacl before but tried it in cygwin
> and got this...
>
> 
> [EMAIL PROTECTED] /cygdrive/c/4up
> $ getfacl *
> # file: 20070709 mach refresh issue
> # owner: daveb
> # group: None
> user::---
> group::---
> group:SYSTEM:rwx
> group:Administrators:rwx
> group:Users:r-x
> mask:rwx
> other:---
> default:group:SYSTEM:rwx
> default:group:Administrators:rwx
> default:group:Users:r-x
> default:mask:rwx
>
> # file: somejunk.txt
> # owner: daveb
> # group: None
> user::---
> group::---
> group:SYSTEM:rwx
> group:Administrators:rwx
> group:Users:r-x
> mask:rwx
> other:---
>
> =
>
> Vista account is only one on machine, has admin privileges.
> UAC is switched on.
> I did have cygwin, hence rsync running normally in this test, but now that
> you remind me, I also tried it before using "Run As Administrator" on
> cygwin. Made no difference.
> Remote unix account is non root... I am using a service provider's Linux
> box, don't know much about the machine, but I have 200GB of file space
> available up there somewhere in the US.
> I can putty to it and type in some commands to report info back if there
> is something specific to find out. Also can talk to their tech support
> 24/7.

Ok, here's a WAG.  Your problem stems from the fact that the Unix
permissions on that directory really are 0.  All of the access information
is stored in separate ACLs, which rsync does not copy.  Thus, it sets the
permissions on the remote copy to 0, and, obviously, is unable to write to
that directory afterwards.

You can run "chmod -R 775" on that directory, which should, if my WAG
above is correct, fix your rsync problem.
Igor
P.S. Before you ask, I'm not awa

Re: rsync problems from Vista installed cygwin, ok on XP

[DaveB]

Corinna Vinschen-2 wrote:
> 
> For testing I copied over the whole /usr directory from my Vista box to
> a Linux machine.  I'm rather puzzled how setting permissions on the
> *remote* machine should be affected by the OS of the source machine.
> 
> I guess we need much more information.  Are the affected directories
> Cygwin-created directories or natively created dirs?  Do they contain
> spaces or native characters?  What are the local permissions on them
> (getfacl/cacls)?  Does your Vista account have admin privileges?  UAC
> switched on?  If so, is rsync running normally with reduced privileges
> or "as administrator"?  Is your remote Unix account root or non-root?
> 
> Corinna
> 


OK, encouraged by hearing that it works for you from Vista to a Linux
machine, I have retraced my steps and tried a much simpler contrived
example.  I set up a little folder tree c:\4up with a single file called
somejunk.txt and one subfolder with two files, a txt and a jpg, latter with
spaces but certainly no special characters.  That's on the Vista pc.  Then I
putty'd across to my ftp area on a Linux server and created a new subfolder
there called .../4up to copy these files to via rsync.  ls shows total 0 in
putty.
Then back on Vista pc in cygwin I cd'd to the 4up folder and typed in this
dry run rsync command

$ rsync -avzn --stats --progress -e ssh . [EMAIL PROTECTED]:/home/xxx/yyy/4up

It happily responded, listing the 2 directories and 3 files and no errors.
I then repeated the command without the dry run -n flag... ie set it live.
It came up with all the errors as before...

==
$ rsync -avz --stats --progress -e ssh . [EMAIL PROTECTED]:/home/xxx/yyy/4up

[EMAIL PROTECTED]'s password:
building file list ...
5 files to consider
./
rsync: failed to modify permissions on "/home/xxx/yyy/4up/.": Permission
denied (13)
rsync: recv_generator: failed to stat "/home/xxx/yyy/4up/somejunk.txt":
Permission denied (13)
20070709 mach refresh issue/
rsync: recv_generator: mkdir "/home/xxx/yyy/4up/20070709 mach refresh issue"
failed: Permission denied (13)
*** Skipping everything below this failed directory ***
rsync: failed to modify permissions on "/home/xxx/yyy/4up/20070709 mach
refresh issue": Permission denied (13)
rsync: recv_generator: mkdir "/home/xxx/yyy/4up/." failed: Permission denied
(13)
*** Skipping everything below this failed directory ***

etc...
===

and after doing this failed rsync, I went back to the putty window to look
at the remote machine and typed ls again... and bingo... permission denied. 
cd .. and ls -l shows the directory 4up with permission now set to 0:
d-   2  x   48 Aug 17 07:42 4up/

===

Let me answer the rest of the questions if I can.
The affected directories are not cygwin created, now or before.  They are
natively created.
They do not contain special chars, nor does the full path to the first file
even contain a space  c:\4up\somjunk.txt but the subfolder and the two files
in it contain spaces.
Local permissions...  haven't used getfacl before but tried it in cygwin and
got this...


[EMAIL PROTECTED] /cygdrive/c/4up
$ getfacl *
# file: 20070709 mach refresh issue
# owner: daveb
# group: None
user::---
group::---
group:SYSTEM:rwx
group:Administrators:rwx
group:Users:r-x
mask:rwx
other:---
default:group:SYSTEM:rwx
default:group:Administrators:rwx
default:group:Users:r-x
default:mask:rwx

# file: somejunk.txt
# owner: daveb
# group: None
user::---
group::---
group:SYSTEM:rwx
group:Administrators:rwx
group:Users:r-x
mask:rwx
other:---

=

Vista account is only one on machine, has admin privileges.
UAC is switched on.
I did have cygwin, hence rsync running normally in this test, but now that
you remind me, I also tried it before using "Run As Administrator" on
cygwin. Made no difference.
Remote unix account is non root... I am using a service provider's Linux
box, don't know much about the machine, but I have 200GB of file space
available up there somewhere in the US.
I can putty to it and type in some commands to report info back if there is
something specific to find out. Also can talk to their tech support 24/7.

-- 
View this message in context: 
http://www.nabble.com/rsync-problems-from-Vista-installed-cygwin%2C-ok-on-XP-tf4260918.html#a12200543
Sent from the Cygwin Users mailing list archive at Nabble.com.


--
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 problems from Vista installed cygwin, ok on XP

[Corinna Vinschen]

On Aug 13 05:28, DaveB wrote:
> 
> My cygwin on Vista seems to work but when I try to do rsync to fixup files on
> my unix ftp server, it chokes with lots of errors and does a bizarre reset
> of the permission bits for the destination folder.  Here's what happens: 
> [this is the same rsync command that works fine on XP]: 
> 
> === 
> $ rsync -avz --stats --progress -e ssh . [EMAIL PROTECTED]:/mypath/wherever/ 
> [EMAIL PROTECTED]'s password: xx 
> building file list ... 
> 8 files to consider 
> ./ 
> rsync: failed to modify permissions on "/mypath/wherever/.": Permission
> denied (13) 
> rsync: recv_generator: failed to stat "/mypath/wherever/firstfile.xxx":
> Permission denied (13) 
> rsync: recv_generator: failed to stat "/mypath/wherever/secondfile.xxx":
> Permission denied (13) 
> ...etc... 
> rsync: recv_generator: mkdir "/mypath/wherever/." failed: Permission denied
> (13) 
> *** Skipping everything below this failed directory *** 

http://cygwin.com/acronyms/#WJFFM

For testing I copied over the whole /usr directory from my Vista box to
a Linux machine.  I'm rather puzzled how setting permissions on the
*remote* machine should be affected by the OS of the source machine.

I guess we need much more information.  Are the affected directories
Cygwin-created directories or natively created dirs?  Do they contain
spaces or native characters?  What are the local permissions on them
(getfacl/cacls)?  Does your Vista account have admin privileges?  UAC
switched on?  If so, is rsync running normally with reduced privileges
or "as administrator"?  Is your remote Unix account root or non-root?


Corinna

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

--
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 problems from Vista installed cygwin, ok on XP

[fraeone]

Unfortunately I'm having exactly the same problem with rsyncing from a Vista
machine to an OS X server. I thought it was because I was using the -a flag
(which includes preserving permissions) but removing that argument didn't
solve the problem.


DaveB wrote:
> 
> My cygwin on Vista seems to work but when I try to do rsync to fixup files
> on my unix ftp server, it chokes with lots of errors and does a bizarre
> reset of the permission bits for the destination folder.  Here's what
> happens: 
> [this is the same rsync command that works fine on XP]: 
> 
> === 
> $ rsync -avz --stats --progress -e ssh .
> [EMAIL PROTECTED]:/mypath/wherever/ 
> [EMAIL PROTECTED]'s password: xx 
> building file list ... 
> 8 files to consider 
> ./ 
> rsync: failed to modify permissions on "/mypath/wherever/.": Permission
> denied (13) 
> rsync: recv_generator: failed to stat "/mypath/wherever/firstfile.xxx":
> Permission denied (13) 
> rsync: recv_generator: failed to stat "/mypath/wherever/secondfile.xxx":
> Permission denied (13) 
> ...etc... 
> rsync: recv_generator: mkdir "/mypath/wherever/." failed: Permission
> denied (13) 
> *** Skipping everything below this failed directory *** 
> 
> ...etc...stats...then... 
> 
> rsync error: some files could not be transferred (code 23) at
> /home/lapo/packaging/tmp/rsync-2.6.6/main.c(791) 
> = 
> 
> Then after I have done this, I find that the remote directory has had all
> its permission bits turned off (chmod 0) and the files in the folder are
> not sync'd.  As I said, this is a sequence I have used many times on XP
> and continues to work there. 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/rsync-problems-from-Vista-installed-cygwin%2C-ok-on-XP-tf4260918.html#a12173918
Sent from the Cygwin Users mailing list archive at Nabble.com.


--
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 problems from Vista installed cygwin, ok on XP

[DaveB]

My cygwin on Vista seems to work but when I try to do rsync to fixup files on
my unix ftp server, it chokes with lots of errors and does a bizarre reset
of the permission bits for the destination folder.  Here's what happens: 
[this is the same rsync command that works fine on XP]: 

=== 
$ rsync -avz --stats --progress -e ssh . [EMAIL PROTECTED]:/mypath/wherever/ 
[EMAIL PROTECTED]'s password: xx 
building file list ... 
8 files to consider 
./ 
rsync: failed to modify permissions on "/mypath/wherever/.": Permission
denied (13) 
rsync: recv_generator: failed to stat "/mypath/wherever/firstfile.xxx":
Permission denied (13) 
rsync: recv_generator: failed to stat "/mypath/wherever/secondfile.xxx":
Permission denied (13) 
...etc... 
rsync: recv_generator: mkdir "/mypath/wherever/." failed: Permission denied
(13) 
*** Skipping everything below this failed directory *** 

...etc...stats...then... 

rsync error: some files could not be transferred (code 23) at
/home/lapo/packaging/tmp/rsync-2.6.6/main.c(791) 
= 

Then after I have done this, I find that the remote directory has had all
its permission bits turned off (chmod 0) and the files in the folder are not
sync'd.  As I said, this is a sequence I have used many times on XP and
continues to work there. 

Any suggestions? 

PS After fixing the documented mkpasswd/Vista problem, cygwin starts without
errors on Vista but then behaves as described above. Here is the output of a
cygcheck -c (I have updated rsync to 2.6.6 as you can see).

C:\cygwin>bin\cygcheck -c
Cygwin Package Information
Package  VersionStatus
_update-info-dir 00516-1OK
alternatives 1.3.29a-1  OK
ash  20040127-3 OK
base-files   3.7-1  OK
base-passwd  2.2-1  OK
bash 3.2.17-15  OK
bzip21.0.3-2OK
catdoc   0.94.2-2   OK
coreutils6.9-2  OK
crypt1.1-1  OK
cygrunsrv1.17-1 OK
cygutils 1.3.1-1OK
cygwin   1.5.24-2   OK
cygwin-doc   1.4-4  OK
diffutils2.8.7-1OK
editrights   1.01-1 OK
enscript 1.6.4-1OK
expat1.95.8-2   OK
findutils4.3.4-1OK
fontconfig   2.4.1-5OK
freetype22.1.9-1OK
gawk 3.1.5-4OK
gdbm 1.8.3-8OK
gettext  0.15-1 OK
grep 2.5.1a-2   OK
groff1.18.1-2   OK
gzip 1.3.12-1   OK
less 381-1  OK
lftp 3.5.9-1OK
libbz2_1 1.0.3-2OK
libdb4.2 4.2.52-1   OK
libdb4.3 4.3.28-1   OK
libexpat01.95.8-2   OK
libfontconfig1   2.4.1-5OK
libfreetype262.1.9-1OK
libgcrypt1.2.1-1OK
libgdbm  1.8.0-5OK
libgdbm-devel1.8.3-8OK
libgdbm3 1.8.3-3OK
libgdbm4 1.8.3-8OK
libgnutls11  1.0.25-2   OK
libgpg-error 1.1-1  OK
libiconv21.11-1 OK
libintl  0.10.38-3  OK
libintl1 0.10.40-1  OK
libintl2 0.12.1-3   OK
libintl3 0.14.5-1   OK
libintl8 0.15-1 OK
libncurses5  5.2-1  OK
libncurses6  5.2-8  OK
libncurses7  5.3-4  OK
libncurses8  5.5-3  OK
libopencdk8  0.5.7-1OK
libpcre0 6.6-1  OK
libpopt0 1.6.4-4OK
libreadline4 4.1-2  OK
libreadline5 4.3-5  OK
libreadline6 5.2.4-8OK
libtasn1 0.2.15-1   OK
libXft   2.1.6-1OK
libXft1  1.0.0-1OK
libXft2  2.1.6-1OK
login1.9-7  OK
man  1.6e-1 OK
minires  1.01-1 OK
mktemp   1.5-4  OK
ncurses  5.5-3  OK
openssh  4.6p1-1OK
openssl  0.9.8e-3   OK
openssl097   0.9.7l-1   OK
pcre 6.6-1  OK
perl 5.8.7-5OK
ping 1.0-1  OK
rebase   2.4.3-1OK
rsync2.6.6-1OK
run  1.1.10-1   OK
sed  4.1.5-2OK
suite3270