(fwd) PATCH: managing permissions with rsyncd.conf options
-- Martin --- Begin Message --- This is a patch to control unix permissions when uploading to a rsyncd-server by setting rsyncd.conf options. cu, Stefan -- Stefan Nehlsen | ParlaNet Administration | [EMAIL PROTECTED] | +49 431 988-1260 rsyncd.conf options to handle file permissions (stolen from samba) This patch is made to provide more control on the permissions of files and directories that are uploaded to a rsyncd-server. Normally when files and directories are uploaded to a rsyncd they are created with the permissions of the source. Especially in the case that user and group are set to special values using the uid and gid directives it does not much sense to use the source permission pattern. There is a patch introducing a new chmod command line option but normally you may want to control the permissions on server side. The patch below will allow you to modify file and directory permissions by using 4 new rsyncd.conf directives. I'm sure that those 2 patches will not break each other and it really makes sense to use them both. You may know this options from samba :-) create mask When a file is created (or touched) by rsyncd the permissions will be taken from the source file bit-wise 'AND'ed with this parameter. This parameter may be thought of as a bit-wise MASK for the UNIX modes of a file. Any bit not set here will be removed from the modes set on a file when it is created. The default value of this parameter is set to 0 to be provide the default behaviour of older versions. Following this rsync will bit-wise 'OR' the UNIX mode created from this parameter with the value of the force create mode parameter which is set to 000 by default. This parameter does not affect directory modes. See the parameter "directory mask" for details. See also the "force create mode" parameter for forcing particular mode bits to be set on created files. See also the "directory mask" parameter for masking mode bits on created directories. Default: create mask = 0 Example: create mask = 0644 force create mode This parameter specifies a set of UNIX mode bit permissions that will always be set on a file created by rsyncd. This is done by bitwise 'OR'ing these bits onto the mode bits of a file that is being created or having its permissions changed. The default for this parameter is (in octal) 000. The modes in this parameter are bitwise 'OR'ed onto the file mode after the mask set in the "create mask" parameter is applied. See also the parameter "create mask" for details on masking mode bits on files. Default: force create mode = 000 Example: force create mode = 0644 directory mask When a directory is created (or touched) by rsyncd the permissions will be taken from the source directory bit-wise 'AND'ed with this parameter. This parameter may be thought of as a bit-wise MASK for the UNIX modes of a file. Any bit not set here will be removed from the modes set on a file when it is created. The default value of this parameter is set to 0 to be provide the default behaviour of older versions. Following this rsync will bit-wise 'OR' the UNIX mode created from this parameter with the value of the "force directory mode" parameter which is set to 000 by default. This parameter does not affect file modes. See the parameter "create mask" for details. See also the "force directory mode" parameter for forcing particular mode bits to be set on created directories. See also the "create mask" parameter for masking mode bits on created files. Default: directory mask = 0 Example: directory mask = 0755 force directory mode This parameter specifies a set of UNIX mode bit permissions that will always be set on a directory created by rsyncd. This is done by bitwise 'OR'ing these bits onto the mode bits of a directory that is being created. The default for this parameter is (in octal) which will not add any extra permission bits to a created directory. This operation is done after the mode mask in the parameter "directory mask" is applied. See also the parameter directory mask for details on masking mode bits on created directories. Default: force directory mode = 000 Example: force directory mode = 0755 diff -ur rsync-2.5.5/loadparm.c rsync-2.5.5-umask/loadparm.c --- rsync-2.5.5/loadparm.c Mon Mar 25 05:04:23 2002 +++ rsync-2.5.5-umask/loadparm.cSun Mar 2 22:53:16 2003 @@ -140,6 +140,10 @@ int timeout; int max_co
rsync creates empty files
hi I'm trying to rsync a directory on my local host to a linux host using the command: rsync -a -v -e ssh "/Users/sir/downloads/CarApp" "[EMAIL PROTECTED]:/home/sir/backup" --progress At first glance, it seems that rsync works perfect, but when I read the files on my linux destination host, all the files are empty! (0 bytes) It is quite confusing. local host: rsync version 2.5.5 protocol version 26 (Mac OS X 10.2.4) linux host: rsync version 2.5.5 protocol version 26 (SuSE Linux 7.3) If I leave the -a away, things get even worse > rsync -ve ssh downloads/CarApp [EMAIL PROTECTED]:~/backup/ca [EMAIL PROTECTED]'s password: skipping directory downloads/CarApp wrote 17 bytes read 20 bytes 8.22 bytes/sec total size is 0 speedup is 0.00 Is there an (obvious) solution for this problem (I'm new to rsync...)? Has anybody else experienced this? alfredo aldundi -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: rsync alternatives for large mirrors?
Mike Loseke wrote: > Anyone here ever use or see any tools (free or commercial) that are > similar to rsync but maybe provide a little more in the way of > reporting features? I'm looking into some possible alternatives to a > system I have scratched together using rsync. I'm bumping into some > issues involved more on the backend of my system (stats on directory > structures and contents) which is limiting the amount of data I can > sync in an 8 hour window to about 120GB. I'd like to be able to sync > 300GB+ in the same timeframe and still get my backend tasks completed. > > Currently those backend tasks that are eating up a fair bit of time > consist of doing a "du" like action on the trees at either end which > is used to generate a report which can be referenced by users so they > know when data is in sync. Ideally I'd like an "update as you go" > sort of method but I haven't figured out a way to do this with rsync. > I do use rsync's output stats in addition to my own. Augment rsync's output stats to include everything you need? Max. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
rsync alternatives for large mirrors?
Anyone here ever use or see any tools (free or commercial) that are similar to rsync but maybe provide a little more in the way of reporting features? I'm looking into some possible alternatives to a system I have scratched together using rsync. I'm bumping into some issues involved more on the backend of my system (stats on directory structures and contents) which is limiting the amount of data I can sync in an 8 hour window to about 120GB. I'd like to be able to sync 300GB+ in the same timeframe and still get my backend tasks completed. Currently those backend tasks that are eating up a fair bit of time consist of doing a "du" like action on the trees at either end which is used to generate a report which can be referenced by users so they know when data is in sync. Ideally I'd like an "update as you go" sort of method but I haven't figured out a way to do this with rsync. I do use rsync's output stats in addition to my own. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
BUG: read: Invalid argument
I'm attempting to mirror a directory tree from debian stable (rsync version 2.5.6cvs) to a win2k box (cygwin, rsync version 2.5.5). This setup/command had previously worked for a bit (cygwin at rsync version 2.4.6 AFAICR), but yesterday it hung, so, finding some mail-list entries about that, I upgraded cygwin, and now I get this: C:\>c:\cygwin\bin\rsync.exe -vv -essh -ac --delete [EMAIL PROTECTED]:/usr/local/cvs /cvs-bup/rsync cmd=ssh machine=boat user=ik path=/usr/local/cvs cmd=ssh -l ik boat rsync --server --sender -vvlogDtprc --delete . /usr/local/cvs opening connection using ssh -l ik boat rsync --server --sender -vvlogDtprc --delete . /usr/local/cvs read: Invalid argument rsync: connection unexpectedly closed (0 bytes read so far) _exit_cleanup(code=12, file=io.c, line=150): entered rsync error: error in rsync protocol data stream (code 12) at io.c(150) _exit_cleanup(code=12, file=io.c, line=150): about to call exit(12) rsync: read error: Connection reset by peer _exit_cleanup(code=12, file=io.c, line=162): entered rsync error: error in rsync protocol data stream (code 12) at io.c(162) _exit_cleanup(code=12, file=io.c, line=162): about to call exit(12) John Kozak -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: patch: typo's and gcc warnings
On Wed, Mar 12, 2003 at 02:58:43PM +0100, Paul Slootman wrote: > On Wed 12 Mar 2003, jw schultz wrote: > > > > I've attached a patch that creates a uint64 for INO64_t and > > DEV64_T and it fixes all the signed-unsigned comparison > > warnings. > > Sure, but that went a bit too far for me at this time. > Your patch looks fine. > > > I've also attached a patch for Makefile.in so that header > > changes will force rebuilds. This one is clearly for > > maintainer convenience. > > Good one. > > > Who will commit these to CVS? Will that happen automagically after > posting here, of does someone need prodding? :-) One of several possibilities exist. Another maintainer with commit privs may check in what he approves, I'll get around to getting commit privs and commit after i get a nod from another maintainer (don't want rogue commits for functional changes), or it will languish. -- J.W. SchultzPegasystems Technologies email address: [EMAIL PROTECTED] Remember Cernan and Schmitt -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: patch against manpage
On Wed, Mar 12, 2003 at 02:55:55PM +0100, Paul Slootman wrote: > On Wed 12 Mar 2003, jw schultz wrote: > > On Wed, Mar 12, 2003 at 01:27:32PM +0100, Paul Slootman wrote: > > > This is a patch against the manpage to clarify what the --perm option > > > does and does not do. > > > > If we are going to embellish this description it would be > > good to make it clear that the behavior of rsync in this > > regard is the same as that of cp. > > > > Most of those complaining about this behavior fail to > > understand it is consistent with cp, scp, rcp et al. > > Not quite true, I'm afraid... > > $ ls -l /tmp/ps* > -rw-rw-r--1 paul paul 1266 Mar 12 14:49 /tmp/ps1 > $ cp /tmp/ps1 /tmp/ps2 > $ ls -l /tmp/ps* > -rw-rw-r--1 paul paul 1266 Mar 12 14:49 /tmp/ps1 > -rw-r--r--1 paul paul 1266 Mar 12 14:51 /tmp/ps2 > > Note how the permissions are different! That's because cp pays attention > to the umask. Only with the -p option does cp preserve the permissions, > even if the destination doesn't exist. And rsync does exactly the same. New file permissions won't be looser than umask but they may be tighter. This is done at the end of receive_file_entry() -- J.W. SchultzPegasystems Technologies email address: [EMAIL PROTECTED] Remember Cernan and Schmitt -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: patch: typo's and gcc warnings
On Wed 12 Mar 2003, jw schultz wrote: > > I've attached a patch that creates a uint64 for INO64_t and > DEV64_T and it fixes all the signed-unsigned comparison > warnings. Sure, but that went a bit too far for me at this time. Your patch looks fine. > I've also attached a patch for Makefile.in so that header > changes will force rebuilds. This one is clearly for > maintainer convenience. Good one. Who will commit these to CVS? Will that happen automagically after posting here, of does someone need prodding? :-) Paul Slootman -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: patch against manpage
On Wed 12 Mar 2003, jw schultz wrote: > On Wed, Mar 12, 2003 at 01:27:32PM +0100, Paul Slootman wrote: > > This is a patch against the manpage to clarify what the --perm option > > does and does not do. > > If we are going to embellish this description it would be > good to make it clear that the behavior of rsync in this > regard is the same as that of cp. > > Most of those complaining about this behavior fail to > understand it is consistent with cp, scp, rcp et al. Not quite true, I'm afraid... $ ls -l /tmp/ps* -rw-rw-r--1 paul paul 1266 Mar 12 14:49 /tmp/ps1 $ cp /tmp/ps1 /tmp/ps2 $ ls -l /tmp/ps* -rw-rw-r--1 paul paul 1266 Mar 12 14:49 /tmp/ps1 -rw-r--r--1 paul paul 1266 Mar 12 14:51 /tmp/ps2 Note how the permissions are different! That's because cp pays attention to the umask. Only with the -p option does cp preserve the permissions, even if the destination doesn't exist. $ cp --version cp (coreutils) 4.5.2 Written by Torbjorn Granlund, David MacKenzie, and Jim Meyering. Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > If i may suggest... > > This option causes rsync to update the permissions > of existing destination files to be the same as the > source files. Like other file copy utilities new > destination files will receive the same permissions > as their source files. Here it's still not clear that the behaviour with new files is the same whether or not the option is specified; that was the original problem. I still think the wording I first used is clearer; if necessary a sentence could be added that the behaviour is the same as other file copy utilities, but I'd be careful about that as I have demonstrated it's not always true, and we also have no idea what file copy utilities the users are accustomed to... Paul Slootman -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
patch: interrupting ssh when it's asking for a password turns offecho in the shell
Here's another scratch for an itch I've been having with rsync (and
there's also a Debian bug report about it). When doing:
rsync -e ssh bla remote:foo
if there's no ssh agent or such, ssh will ask for a password or
passphrase. If you then hit ctrl-C, rsync will terminate, but the shell
will not echo as rsync has killed ssh before ssh had a chance to restore
the termio settings (ssh has already received the initial signal, but
before it can proceed it gets a SIGUSR1 from rsync).
As I'm not clear on all the different ways the exit_cleanup function can
be called, I couldn't really determine how to fix this problem cleanly.
I came up with a small delay before the wait on child processes, and
this seems to work fine for me. AFAICS this patch shouldn't cause any
trouble on other platforms in any way.
Paul Slootman
--- ../../orig/rsync-2.5.6/cleanup.c2003-01-27 04:35:08.0 +0100
+++ ./cleanup.c 2003-03-12 14:31:04.0 +0100
@@ -104,6 +104,16 @@
if (cleanup_child_pid != -1) {
int status;
+ /* if the user hits ctrl-C while ssh is prompting for a password,
+* then the kill_all() below may kill ssh before ssh has a
+* chance to restore the tty settings (i.e. turn echo back on).
+* By sleeping for a short time, ssh gets a bigger chance to
+* do the right thing. When ssh exits, the select() in msleep()
+* will be interrupted by SIGCHLD anyway.
+* If child processes are not ssh waiting for a password, then
+* this tiny delay shouldn't hurt anything.
+*/
+ msleep(400);
if (waitpid(cleanup_child_pid, &status, WNOHANG) == cleanup_child_pid)
{
status = WEXITSTATUS(status);
if (status > code) code = status;
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: patch: typo's and gcc warnings
On Wed, Mar 12, 2003 at 01:34:58PM +0100, Paul Slootman wrote: > Two patches: > one to correct the spelling of permissions (in comments, but such typos > disturb me as well), and OK. I can't speel but but spelling errors impede clarity. > one to cast inode and dev to unsigned long before comparing, to prevent > gcc giving a warning "comparison between signed and unsigned". > > > Paul Slootman [snip] > diff -ru orig/rsync-2.5.6/receiver.c rsync-2.5.6/receiver.c > --- orig/rsync-2.5.6/receiver.c 2003-01-21 00:32:17.0 +0100 > +++ rsync-2.5.6/receiver.c2003-03-10 16:28:10.0 +0100 > @@ -55,8 +55,8 @@ > if (link_stat(f_name(flist->files[j]), &st)) return 1; > > for (i=0;i - if (st.st_ino == delete_list[i].inode && > - st.st_dev == delete_list[i].dev) > + if (st.st_ino == (unsigned long)delete_list[i].inode && > + st.st_dev == (unsigned long)delete_list[i].dev) > return 1; > } I don't think this is the right fix. Among other things it would break things if ino_t or dev_t were a long long. What we should be doing is even mentioned in rsync.h: | * FIXME: Really we need an unsigned type, and we perhaps | * ought to | * cope with platforms on which this is an unsigned int or | * even a | * struct. Later. | */ | #define INO64_T int64 | #define DEV64_T int64 I've attached a patch that creates a uint64 for INO64_t and DEV64_T and it fixes all the signed-unsigned comparison warnings. I've also attached a patch for Makefile.in so that header changes will force rebuilds. This one is clearly for maintainer convenience. -- J.W. SchultzPegasystems Technologies email address: [EMAIL PROTECTED] Remember Cernan and Schmitt Index: Makefile.in === RCS file: /cvsroot/rsync/Makefile.in,v retrieving revision 1.89 diff -u -b -r1.89 Makefile.in --- Makefile.in 20 Jan 2003 18:26:14 - 1.89 +++ Makefile.in 12 Mar 2003 13:23:36 - @@ -25,6 +25,7 @@ .SUFFIXES: .SUFFIXES: .c .o +HEADERS=byteorder.h errcode.h proto.h rsync.h LIBOBJ=lib/fnmatch.o lib/compat.o lib/snprintf.o lib/mdfour.o \ lib/permstring.o @LIBOBJS@ ZLIBOBJ=zlib/deflate.o zlib/infblock.o zlib/infcodes.o zlib/inffast.o \ @@ -74,6 +75,9 @@ $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $(OBJS) $(LIBS) $(OBJS): config.h + +config.h: $(HEADERS) + touch $@ tls$(EXEEXT): $(TLS_OBJ) $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $(TLS_OBJ) $(LIBS) Index: rsync.h === RCS file: /cvsroot/rsync/rsync.h,v retrieving revision 1.137 diff -u -b -r1.137 rsync.h --- rsync.h 18 Feb 2003 18:07:36 - 1.137 +++ rsync.h 12 Mar 2003 13:22:47 - @@ -261,15 +261,20 @@ #if HAVE_OFF64_T #define int64 off64_t +#define uint64 off64_t #elif (SIZEOF_LONG == 8) #define int64 long +#define uint64 unsigned long #elif (SIZEOF_INT == 8) #define int64 int +#define uint64 unsigned int #elif HAVE_LONGLONG #define int64 long long +#define uint64 unsigned long long #else /* As long as it gets... */ #define int64 off_t +#define uint64 off_t #define NO_INT64 #endif @@ -304,8 +309,8 @@ * cope with platforms on which this is an unsigned int or even a * struct. Later. */ -#define INO64_T int64 -#define DEV64_T int64 +#define INO64_T uint64 +#define DEV64_T uint64 #ifndef MIN #define MIN(a,b) ((a)<(b)?(a):(b)) -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: patch against manpage
On Wed, Mar 12, 2003 at 01:27:32PM +0100, Paul Slootman wrote: > This is a patch against the manpage to clarify what the --perm option > does and does not do. If we are going to embellish this description it would be good to make it clear that the behavior of rsync in this regard is the same as that of cp. Most of those complaining about this behavior fail to understand it is consistent with cp, scp, rcp et al. If i may suggest... This option causes rsync to update the permissions of existing destination files to be the same as the source files. Like other file copy utilities new destination files will receive the same permissions as their source files. > > > Paul Slootman > diff -ru orig/rsync-2.5.6/rsync.1 rsync-2.5.6/rsync.1 > --- orig/rsync-2.5.6/rsync.1 2003-01-28 04:11:57.0 +0100 > +++ rsync-2.5.6/rsync.1 2003-03-07 12:18:19.0 +0100 > @@ -562,8 +562,13 @@ > default\&. > .IP > .IP "\fB-p, --perms\fP" > -This option causes rsync to update the remote > -permissions to be the same as the local permissions\&. > +This option causes rsync to update the destination file's > +permissions to be the same as the source's permissions\&. > +Whether or not this option is specified, destination permissions for > +newly created files are ALWAYS the same as the source permissions\&. > +I.e. this option only affects whether the permissions on existing > +destination files are updated or not\&. > + > .IP > .IP "\fB-o, --owner\fP" > This option causes rsync to set the owner of the > -- > To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync > Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html -- J.W. SchultzPegasystems Technologies email address: [EMAIL PROTECTED] Remember Cernan and Schmitt -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
patch: typo's and gcc warnings
Two patches:
one to correct the spelling of permissions (in comments, but such typos
disturb me as well), and
one to cast inode and dev to unsigned long before comparing, to prevent
gcc giving a warning "comparison between signed and unsigned".
Paul Slootman
diff -ru orig/rsync-2.5.6/generator.c rsync-2.5.6/generator.c
--- orig/rsync-2.5.6/generator.c2002-08-29 16:44:55.0 +0200
+++ rsync-2.5.6/generator.c 2003-03-07 12:06:57.0 +0100
@@ -241,7 +241,7 @@
!preserve_perms &&
(S_ISDIR(st.st_mode) == S_ISDIR(file->mode))) {
/* if the file exists already and we aren't perserving
- presmissions then act as though the remote end sent
+ permissions then act as though the remote end sent
us the file permissions we already have */
file->mode = (file->mode & _S_IFMT) | (st.st_mode & ~_S_IFMT);
}
diff -ru orig/rsync-2.5.6/receiver.c rsync-2.5.6/receiver.c
--- orig/rsync-2.5.6/receiver.c 2003-01-21 00:32:17.0 +0100
+++ rsync-2.5.6/receiver.c 2003-03-10 16:28:10.0 +0100
@@ -396,8 +396,8 @@
}
if (fd1 != -1 && !preserve_perms) {
- /* if the file exists already and we aren't perserving
- presmissions then act as though the remote end sent
+ /* if the file exists already and we aren't preserving
+ permissions then act as though the remote end sent
us the file permissions we already have */
file->mode = st.st_mode;
}
diff -ru orig/rsync-2.5.6/receiver.c rsync-2.5.6/receiver.c
--- orig/rsync-2.5.6/receiver.c 2003-01-21 00:32:17.0 +0100
+++ rsync-2.5.6/receiver.c 2003-03-10 16:28:10.0 +0100
@@ -55,8 +55,8 @@
if (link_stat(f_name(flist->files[j]), &st)) return 1;
for (i=0;i--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
patch against manpage
This is a patch against the manpage to clarify what the --perm option does and does not do. Paul Slootman diff -ru orig/rsync-2.5.6/rsync.1 rsync-2.5.6/rsync.1 --- orig/rsync-2.5.6/rsync.12003-01-28 04:11:57.0 +0100 +++ rsync-2.5.6/rsync.1 2003-03-07 12:18:19.0 +0100 @@ -562,8 +562,13 @@ default\&. .IP .IP "\fB-p, --perms\fP" -This option causes rsync to update the remote -permissions to be the same as the local permissions\&. +This option causes rsync to update the destination file's +permissions to be the same as the source's permissions\&. +Whether or not this option is specified, destination permissions for +newly created files are ALWAYS the same as the source permissions\&. +I.e. this option only affects whether the permissions on existing +destination files are updated or not\&. + .IP .IP "\fB-o, --owner\fP" This option causes rsync to set the owner of the -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: File name too long
On Wed, Mar 12, 2003 at 12:23:30PM +0100, Paul Slootman wrote:
> On Wed 12 Mar 2003, jw schultz wrote:
> >
> > Not quite final. I really didn't like calling strcpy for
> > single chars so i fixed that. Also strlcpy counts the null
>
> I was thinking of this, but I'm optimistic that gcc will unroll such
> things...
Unroll, no. Inline, possible but not really desirable.
Cache effects, you know. In any case the null tests etc.
just make it overkill.
>
> > in the length so a small adjustment had to be made.
>
> True.
> Furthermore, ensuring that it's always null-terminated all the time
> isn't necessary, but will of course help against screwups in the future.
Precisely, unterminated strings are hazardous for long-term
maintenance.
>
> > Here it is in as a patch to cvs. Ready for commit since i
> > don't have that privilege yet. It builds and passes the
> > testsuite.
>
> Hmm, could you also give it as the plain function? Makes it easier for
> me to paste it in my already hacked copy.
Also attached.
>
> > @@ -435,7 +458,7 @@
> > fd2 = do_mkstemp(fnametmp, file->mode & INITACCESSPERMS);
> > }
> > if (fd2 == -1) {
> > - rprintf(FERROR,"mkstemp %s failed:
> > %s\n",fnametmp,strerror(errno));
> > + rprintf(FERROR,"mkstemp s %s failed: %s\n", fname,
> > strerror(errno));
>
> What's the " s " for?
Leftovers from integration debugging (one dw too few).
Fresh copy attached.
--
J.W. SchultzPegasystems Technologies
email address: [EMAIL PROTECTED]
Remember Cernan and Schmitt
Index: receiver.c
===
RCS file: /cvsroot/rsync/receiver.c,v
retrieving revision 1.41
diff -u -b -r1.41 receiver.c
--- receiver.c 20 Jan 2003 23:32:17 - 1.41
+++ receiver.c 12 Mar 2003 12:04:30 -
@@ -164,40 +164,63 @@
}
+/*
+ * get_tmpname() - create a tmp filename for a given filename
+ *
+ * If a tmpdir is defined, use that as the directory to
+ * put it in. Otherwise, the tmp filename is in the same
+ * directory as the given name. Note that there may be no
+ * directory at all in the given name!
+ *
+ * The tmp filename is basically the given filename with a
+ * dot prepended, and .XX appended (for mkstemp() to
+ * put its unique gunk in). Take care to not exceed
+ * either the MAXPATHLEN or NAME_MAX, esp. the last, as
+ * the basename basically becomes 8 chars longer. In that
+ * case, the original name is shortened sufficiently to
+ * make it all fit.
+ *
+ * Of course, there's no real reason for the tmp name to
+ * look like the original, except to satisfy us humans.
+ * As long as it's unique, rsync will work.
+ */
+
static int get_tmpname(char *fnametmp, char *fname)
{
char *f;
+ int length = 0;
+ int maxname;
- /* open tmp file */
if (tmpdir) {
- f = strrchr(fname,'/');
- if (f == NULL)
- f = fname;
- else
- f++;
- if (strlen(tmpdir)+strlen(f)+10 > MAXPATHLEN) {
- rprintf(FERROR,"filename too long\n");
- return 0;
+ strlcpy(fnametmp, tmpdir, MAXPATHLEN - 2);
+ length = strlen(fnametmp);
+ fnametmp[length++] = '/';
+ fnametmp[length] = '\0';/* always NULL terminated */
}
- snprintf(fnametmp,MAXPATHLEN, "%s/.%s.XX",tmpdir,f);
- return 1;
+
+ if ((f = strrchr(fname, '/'))) {/* extra () for gcc */
+ ++f;
+ if (!tmpdir) {
+ length = f - fname;
+ strlcpy(fnametmp, fname, length + 1);
+ } /* copy up to and including the slash */
+ } else {
+ f = fname;
}
+ fnametmp[length++] = '.';
+ fnametmp[length] = '\0';/* always NULL terminated */
- f = strrchr(fname,'/');
+ maxname = MIN(MAXPATHLEN - 7 - length, NAME_MAX - 8);
- if (strlen(fname)+9 > MAXPATHLEN) {
- rprintf(FERROR,"filename too long\n");
+ if (maxname < 1)
+ {
+ rprintf(FERROR, "temporary filename too long: %s\n", fname);
+ fnametmp[0] = '\0';
return 0;
}
- if (f) {
- *f = 0;
- snprintf(fnametmp,MAXPATHLEN,"%s/.%s.XX",
-fname,f+1);
- *f = '/';
- } else {
- snprintf(fnametmp,MAXPATHLEN,".%s.XX",fname);
- }
+ strlcpy(fnametmp + length, f, maxname);
+ strcat(fnametmp + length, ".XX");
return 1;
}
Index: rsync.h
==
Re: File name too long
On Wed 12 Mar 2003, jw schultz wrote:
>
> Not quite final. I really didn't like calling strcpy for
> single chars so i fixed that. Also strlcpy counts the null
I was thinking of this, but I'm optimistic that gcc will unroll such
things...
> in the length so a small adjustment had to be made.
True.
Furthermore, ensuring that it's always null-terminated all the time
isn't necessary, but will of course help against screwups in the future.
> Here it is in as a patch to cvs. Ready for commit since i
> don't have that privilege yet. It builds and passes the
> testsuite.
Hmm, could you also give it as the plain function? Makes it easier for
me to paste it in my already hacked copy.
> @@ -435,7 +458,7 @@
> fd2 = do_mkstemp(fnametmp, file->mode & INITACCESSPERMS);
> }
> if (fd2 == -1) {
> - rprintf(FERROR,"mkstemp %s failed:
> %s\n",fnametmp,strerror(errno));
> + rprintf(FERROR,"mkstemp s %s failed: %s\n", fname,
> strerror(errno));
What's the " s " for?
Paul Slootman
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: File name too long
On Wed, Mar 12, 2003 at 10:27:38AM +0100, Paul Slootman wrote:
> On Tue 11 Mar 2003, jw schultz wrote:
> >
> > I threw this out there because it looked like we were
> > heading towards a rewrite of the whole function and i wanted
> > to rethink it instead of just reworking parts of it. If a
> > concensus is that this is the way to go i'm all for that.
> > If the pointer arithmatic is too offensive that's fine too.
>
> A rewrite is fine; and personally I like pointer arithmetic :-)
>
> So this is a final draft IMHO:
>
>
> /**
> * get_tmpname() - create a tmp filename for a given filename
> * If a tmpdir is defined, use that as the directory to put it in.
> * Otherwise, the tmp filename is in the same directory as the given name.
> * Note that there may be no directory at all in the given name!
> *
> * The tmp filename is basically the given filename with a dot prepended,
> * and .XX appended (for mkstemp() to put its unique gunk in).
> * Take care to not exceed either the MAXPATHLEN or NAME_MAX, esp. the
> * last, as the basename basically becomes 8 chars longer. In that case,
> * the original name is shortened sufficiently to make it all fit.
> *
> * Of course, there's no real reason for the tmp name to look like the
> * original, except to satisfy us humans. As long as it's unique, rsync
> * will work.
> */
> static int get_tmpname(char *fnametmp, char *fname)
> {
> char*f;
> int length = 0;
> int maxname;
>
> if (tmpdir) {
> strlcpy(fnametmp, tmpdir, MAXPATHLEN - 2);
> length = strlen(fnametmp);
> strcpy(fnametmp + length++, "/");
> }
>
> if ((f = strrchr(fname, '/'))) {
> ++f;
> if (!tmpdir) {
> /* copy up to and including the slash */
> length = f - fname;
> strlcpy(fnametmp, fname, length);
> }
> }
> else {
> f = fname;
> }
> strcpy(fnametmp + length++, ".");
>
> maxname = MIN(MAXPATHLEN - 7 - length, NAME_MAX - 8);
>
> if (maxname < 1) {
> rprintf(FERROR, "temporary filename too long: %s\n", fname);
> return 0;
> }
>
> strlcpy(fnametmp + length, f, maxname);
> strcat(fnametmp + length, ".XX");
>
> return 1;
> }
Not quite final. I really didn't like calling strcpy for
single chars so i fixed that. Also strlcpy counts the null
in the length so a small adjustment had to be made.
Here it is in as a patch to cvs. Ready for commit since i
don't have that privilege yet. It builds and passes the
testsuite.
--
J.W. SchultzPegasystems Technologies
email address: [EMAIL PROTECTED]
Remember Cernan and Schmitt
Index: receiver.c
===
RCS file: /cvsroot/rsync/receiver.c,v
retrieving revision 1.41
diff -b -u -r1.41 receiver.c
--- receiver.c 20 Jan 2003 23:32:17 - 1.41
+++ receiver.c 12 Mar 2003 11:08:36 -
@@ -164,40 +164,63 @@
}
+/*
+ * get_tmpname() - create a tmp filename for a given filename
+ *
+ * If a tmpdir is defined, use that as the directory to
+ * put it in. Otherwise, the tmp filename is in the same
+ * directory as the given name. Note that there may be no
+ * directory at all in the given name!
+ *
+ * The tmp filename is basically the given filename with a
+ * dot prepended, and .XX appended (for mkstemp() to
+ * put its unique gunk in). Take care to not exceed
+ * either the MAXPATHLEN or NAME_MAX, esp. the last, as
+ * the basename basically becomes 8 chars longer. In that
+ * case, the original name is shortened sufficiently to
+ * make it all fit.
+ *
+ * Of course, there's no real reason for the tmp name to
+ * look like the original, except to satisfy us humans.
+ * As long as it's unique, rsync will work.
+ */
+
static int get_tmpname(char *fnametmp, char *fname)
{
char *f;
+ int length = 0;
+ int maxname;
- /* open tmp file */
if (tmpdir) {
- f = strrchr(fname,'/');
- if (f == NULL)
- f = fname;
- else
- f++;
- if (strlen(tmpdir)+strlen(f)+10 > MAXPATHLEN) {
- rprintf(FERROR,"filename too long\n");
- return 0;
+ strlcpy(fnametmp, tmpdir, MAXPATHLEN - 2);
+ length = strlen(fnametmp);
+ fnametmp[length++] = '/';
+ fnametmp[length] = '\0';/* always NULL terminated */
}
- snprintf(fnametmp,MAXPATHLEN, "%s/.%s.XX",tmpdir,f);
- return 1;
+
+ if ((f = strrchr(fname, '/'))) {/* extra ()
Re: Problems with ! -p
On Wed, Mar 12, 2003 at 01:26:34PM +1100, David Leach wrote: > Hi there, > > rsync version 2.5.5 protocol version 26. > > I seem to be having some trouble using rsync to ignore permissions on a > remote host when syncing back to a local host. I want it to listen to > the umask of the user running the rsync locally. Eg: > > [remote host - I've touched a file made it 4750, etc, etc] > hostb $ mkdir -p /data/rsync/temp > hostb $ touch /data/rsync/temp/foo > hostb $ chgrp blah /data/rsync/temp/foo > hostb $ chmod 4750 /data/rsync/temp/foo > hostb $ ls -lR /data/rsync/temp > /data/rsync/temp: > total 0 > -rwsr-x--- 1 rsyncblah 0 Mar 12 13:14 foo > > [hosta, I run an rsync and get the following result] > hosta $ ls -lR /data/rsync/temp > /data/rsync/temp: No such file or directory > hosta $ rsync -e ssh --rsync-path=/opt/local/bin/rsync -rtl > hostb:/data/rsync/temp /data/rsync/ > hosta $ ls -lR /data/rsync/temp > /data/rsync/temp: > total 0 > -rwsr-x--- 1 rsyncrsync 0 Mar 12 13:14 foo > > The group is lost, however the permissions are preserved. How can I > prevent this happening? Thanks in advance! There is a chmod-patch that adds a new command line switch to modify permissions on the receiving side. rsync seems to work like cp unless you specify -p. My rsyncd-perm-patch only works in rsyncd mode on server side into the other direction. (It handles a simular problem.) cu, Stefan -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: rsync reference case
We use it for as off-site backup for 35 sites, 700 GB in total. "We" are Sita, part of the Suez-group. Kind regards, Bart Coninckx Network Administrator CNE, ASE * Sita ICT Services Lilsedijk 19 B-2340 Beerse Belgium e-mail: [EMAIL PROTECTED] Tel: + 32 (0) 14 62 28 22 Fax: + 32 (0) 14 62 41 47 * Simon Szeto <[EMAIL PROTECTED]> Sent by: To: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: .samba.orgSubject: rsync reference case 12/03/2003 03:13 Dear all, I would like to propose rysnc feature to our customer. Do you have any reference case from other company that there is using rsync in the production server? regards, Simon _ §ÚªºÅº¶Æ(®e¯ª¨à)¡A¥ª¾F¥k¨½(§õ§J¶Ô)¡A§A³Ì¬õ(Twins)... ¹L¤dº¤â¾÷¹aÁn ÂIRing³£±o http://ringtone.yahoo.com.hk -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: File name too long
On Tue 11 Mar 2003, jw schultz wrote:
>
> I threw this out there because it looked like we were
> heading towards a rewrite of the whole function and i wanted
> to rethink it instead of just reworking parts of it. If a
> concensus is that this is the way to go i'm all for that.
> If the pointer arithmatic is too offensive that's fine too.
A rewrite is fine; and personally I like pointer arithmetic :-)
So this is a final draft IMHO:
/**
* get_tmpname() - create a tmp filename for a given filename
* If a tmpdir is defined, use that as the directory to put it in.
* Otherwise, the tmp filename is in the same directory as the given name.
* Note that there may be no directory at all in the given name!
*
* The tmp filename is basically the given filename with a dot prepended,
* and .XX appended (for mkstemp() to put its unique gunk in).
* Take care to not exceed either the MAXPATHLEN or NAME_MAX, esp. the
* last, as the basename basically becomes 8 chars longer. In that case,
* the original name is shortened sufficiently to make it all fit.
*
* Of course, there's no real reason for the tmp name to look like the
* original, except to satisfy us humans. As long as it's unique, rsync
* will work.
*/
static int get_tmpname(char *fnametmp, char *fname)
{
char*f;
int length = 0;
int maxname;
if (tmpdir) {
strlcpy(fnametmp, tmpdir, MAXPATHLEN - 2);
length = strlen(fnametmp);
strcpy(fnametmp + length++, "/");
}
if ((f = strrchr(fname, '/'))) {
++f;
if (!tmpdir) {
/* copy up to and including the slash */
length = f - fname;
strlcpy(fnametmp, fname, length);
}
}
else {
f = fname;
}
strcpy(fnametmp + length++, ".");
maxname = MIN(MAXPATHLEN - 7 - length, NAME_MAX - 8);
if (maxname < 1) {
rprintf(FERROR, "temporary filename too long: %s\n", fname);
return 0;
}
strlcpy(fnametmp + length, f, maxname);
strcat(fnametmp + length, ".XX");
return 1;
}
The extra parentheses around the strrchr thing is to keep gcc quiet.
Paul Slootman
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: File name too long
A 20:02 11/03/2003 +0100, Paul Slootman a écrit : On Tue 11 Mar 2003, Luc Santeramo wrote: > A 16:19 11/03/2003 +0100, Paul Slootman a écrit : > >On Tue 11 Mar 2003, Luc Santeramo wrote: > > > >> maybe you can send me receiver.c ? > > > >Done. > > ok I got it > but maybe I should wait for you and JW to agree on this part ? Well, it's basically just different implementations, the version I sent you will work fine. It depends on whether you need this to work right away, or whether you're happy with waiting for us to whack out a new version :-) Anyway, I expect that we'll have a final version tomorrow. And as a newcomer to rsync hacking, I don't know how soon this will be accepted into the official sources (can JW commit?) the patch you gave works fine. thanks. now I can wait for the official version without problem. Luc -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
