On Mon, Jan 20, 2003 at 07:00:55PM -0600, Dave Dykstra wrote:
> I submitted a change to ignore errors from chmod when -p is not set.
> GNU cp does the same thing.
>
> - Dave Dykstra
Fair enough. It is an isane condition except for filesystem
semantics mismatch.
> On Mon, Jan 13, 2003 at 01:13:4
I submitted a change to ignore errors from chmod when -p is not set.
GNU cp does the same thing.
- Dave Dykstra
On Mon, Jan 13, 2003 at 01:13:48PM -0800, jw schultz wrote:
> On Mon, Jan 13, 2003 at 02:38:29PM -0600, Dave Dykstra wrote:
> > On Mon, Jan 13, 2003 at 11:00:58AM -0800, Ben wrote:
> >
On Mon, Jan 13, 2003 at 02:38:29PM -0600, Dave Dykstra wrote:
> On Mon, Jan 13, 2003 at 11:00:58AM -0800, Ben wrote:
> > Well that's annoying. I've tried changing the encoding of this
> > attempt... maybe it'll get through this time.
>
> Yes, it came through better this time.
>
> > As a rule of t
On Mon, Jan 13, 2003 at 11:00:58AM -0800, Ben wrote:
> Well that's annoying. I've tried changing the encoding of this
> attempt... maybe it'll get through this time.
Yes, it came through better this time.
> As a rule of thumb, I think silent errors a very bad idea. It means
> things might not be
Well that's annoying. I've tried changing the encoding of this
attempt... maybe it'll get through this time.
As a rule of thumb, I think silent errors a very bad idea. It means
things might not be behaving like you expect, but you have no idea. In
general, rsync's current behavior is correct. In m
On Sat, Jan 11, 2003 at 11:19:33AM -0800, Ben wrote [off list]:
> On Tue, 2003-01-07 at 14:49, Dave Dykstra wrote:
> > That sounds reasonable to me that rsync shouldn't try to preserve those
> > extra bits without -p. Try making a patch and seeing if that works.
> >
> > I don't have Samba set up,
That sounds reasonable to me that rsync shouldn't try to preserve those
extra bits without -p. Try making a patch and seeing if that works.
I don't have Samba set up, but on a vfat filesystem on Linux rsync is
doing even worse because after the initial file creation it does a
"fchmod(fd, 0600)" w
I'm not sure what POSIX calls for, but on both Linux and AIX (the two
unix OSes I have access to) I can leave off the mode arg when calling
open(2). Granted, doing so gives me a mode that normally isn't so good,
but in my case this would be fine, as I have samba forcing modes to be
what I want them
Ben [mailto:[EMAIL PROTECTED]]
> I'm relatively new to rsync, but it seems to me that if there's an
> option to perserve permissions and you don't set it, then rsync
> shouldn't do anything with permissions.
Sounds good, but recall how POSIX / Unix system calls work. To create a
file, you have to
I'm relatively new to rsync, but it seems to me that if there's an
option to perserve permissions and you don't set it, then rsync
shouldn't do anything with permissions.
I think having chmod silently fail in the absence of -p works here as
well, but I may well not be thinking about all cases.
On
OK, now I understand. I have seen those errors also when writing onto a
PC filesystem mounted by Linux. Other programs like tar and cpio have
the same problem, so I've just ignored the messages. Maybe everybody
else does the same. Maybe a well thought out and documented patch for
a new flag wou
On Tue, Dec 31, 2002 at 08:06:52AM -0800, Ben wrote:
> No, these are for new files. Existing files work perfectly, but, like
> you said before, for new files rsync creates the file then attempts to
> alter the permissions based on the origional permissions and umask.
>
> > On Mon, Dec 30, 2002 at
Yeah, my problem is that the chmod fails, so then rsync complains not
everything worked as expected. Because I'm writing files to a network
mount with forced permissions, I would like a way for rsync to simply
create the file and never try to chmod what it creates. Normally that
would probably be a
Then what would you expect it to do? I'm guessing your only problem is
that the chmod is failing, and you would rather have it create files with
the final permissions in the first place; is that it? I believe it is
done this way because of worries of potential security problems, where
temporary f
No, these are for new files. Existing files work perfectly, but, like
you said before, for new files rsync creates the file then attempts to
alter the permissions based on the origional permissions and umask.
On Tue, 2002-12-31 at 07:58, Dave Dykstra wrote:
> What do you mean, "altered"? Do the
What do you mean, "altered"? Do the destination files already exist?
It is supposed to preserve existing permissions on destination files
when you don't use -p.
- Dave
On Mon, Dec 30, 2002 at 06:44:24PM -0800, Ben wrote:
> Hmmm... while that makes sense, that doesn't really help me in my
> situ
Hmmm... while that makes sense, that doesn't really help me in my
situation, where permissions cannot be altered because of the network
mount they are being written to.
Does it make sense to impliment a "don't touch permissions" flag?
On Tue, 2002-12-24 at 05:08, Dave Dykstra wrote:
> When preser
When preserve_perms is not set, rsync sets a default permission based on
the original permissions and the umask. A comment in flist.c says that is
what GNU cp does, so that's why rsync does it. Comments in generator.c
and receiver.c indicate that if a file already exists and preserve_perms
isn't
They seem to be for me, even when I don't pass in the --perms flag. This
is a problem because I'm rsyncing to a samba mount with fixed
permissions.
Looking at rsync.c (for version 2.5.5) starting at line 204, I see this
code snippet:
#ifdef HAVE_CHMOD
if (!S_ISLNK(st->st_mode)) {
if (
19 matches
Mail list logo
