Re: bug in permissions on symlinks
On Mon, Dec 03, 2001 at 12:42:19PM -0600, Dave Dykstra [EMAIL PROTECTED] wrote: | On Sun, Dec 02, 2001 at 11:52:08PM +1100, Martin Pool wrote: | I see rsync has this in rsync.h |#ifndef HAVE_LCHOWN |#define lchown chown |#endif Ick! | I'm not at all sure the way we're calling it is correct. There could | be systems where there is no lchown, but chown on a symlink still | follows the link. I seem to remember Solaris behaving this way, but | I'm not sure if that is the system call or just the chown command. The command definitely follows the link. | In this case we might be accidentally setting the ownership of the | destination. On such a machine we should just not set the ownership | of the symlink at all. Definitely. Chown following symlinks is one reason I NEVER use the chmod -R and chown -R commands, instead playing annoying games with find ! -type l -print | xargs | No, I don't. Even my oldest systems have symbolic links and also have | lchown. I think any system that has symbolic links would have to | implement the lchown/chown distinction, so I don't think it's something | to worry about. Not so. The sunos4 boxen don't have lchown(), and I'd expect the orignal BSD stuff where symlinks came in didn't have it. (I certainly had never tripped over it). Another counter example - Apollo symlinks were special directory entries, not objects with inodes, and chowning them was meaningless. SInce the target permissions were always enough anyway (permissions on a symlinks can be trivially bypassed by opening the full path, and symlinks are not writable themself - only creatable), so inodeless implementations are both feasible and sensible. Please - if there's no lchown DO NOT chown symlinks. It is silently destructive. RANT It has long offended me that the default chown/chgrp/chmod calls follow links - to my mind the _only_ system calls that should follow links are open() and chdir(). It would have made for a much saner and safer world. /RANT -- Cameron Simpson, DoD#743[EMAIL PROTECTED]http://www.zip.com.au/~cs/ You've failed to miss my point entirely, though you've succeeded mostly. - Mark Vieselmeyer
Re: bug in permissions on symlinks
On Fri, Dec 07, 2001 at 12:58:31AM +1100, Cameron Simpson wrote: ... Not so. The sunos4 boxen don't have lchown() You're right. However, the chown man page says it doesn't follow symlinks: If the final component of path is a symbolic link, the own- ership and group of the symbolic link is changed, not the ownership and group of the file or directory to which it points. and I'd expect the orignal BSD stuff where symlinks came in didn't have it. (I certainly had never tripped over it). I don't have any other BSD systems, but I would think they'd be like Sunos4. Another counter example - Apollo symlinks were special directory entries, not objects with inodes, and chowning them was meaningless. SInce the target permissions were always enough anyway (permissions on a symlinks can be trivially bypassed by opening the full path, and symlinks are not writable themself - only creatable), so inodeless implementations are both feasible and sensible. Does anybody run rsync on Apollo? Please - if there's no lchown DO NOT chown symlinks. It is silently destructive. I say let's don't bother to change it unless somebody reports a problem. RANT It has long offended me that the default chown/chgrp/chmod calls follow links - to my mind the _only_ system calls that should follow links are open() and chdir(). It would have made for a much saner and safer world. /RANT Looks like the BSD inventors of symlinks agreed with you for chown chgrp (but not chmod). Only SystemV messed up when they added symlinks, and as a result had to come up with lchown. - Dave Dykstra
Re: Netware modify bit changed
I think that what Juan means is that when you rsync from one system where the archive bit is unset, to another place, these files, which were archive=0 on their source, are new creations on the target system, and have the archive bit set. Rsync has no provision to preserve these attributes, as there's really no unix attribute corresponding to the dos archive attribute. I'm guessing that system isn't preserved, either, and i wonder what the handling of read-only and hidden would be... is readonly equivalent to ugo-w, and is hidden ugo-r? The unix attribute for hidden is to start the filename with a dot. I would expect the dos attributes to just be ignored, and a readonly, system, hidden, readonly file from one system would arrive at another system as a non-system, readwrite, visible file, with the archive attribute set. Incidentally, since it's netware-to-netware, what about NCP? I don't know much about it, but i understand that it transfers the underlying netware information instead of going through all the filesystem layers... very fast, and i think it can go system-to-system within a netware domain. Does it still even exist post 3.12? On 5 Dec 2001, Juan J. L?pez [EMAIL PROTECTED] wrote: Dave: With archive bit I mean a MS-DOS file attribute (like read only, system or hidden). When the archive attribute of a file is set, that file is presumed to be changed after the last backup and then must be copied again. The backup aplication Tim Conway [EMAIL PROTECTED] 303.682.4917 Philips Semiconductor - Longmont TC 1880 Industrial Circle, Suite D Longmont, CO 80501 Available via SameTime Connect within Philips, n9hmg on AIM perl -e 'print pack(, 19061,29556,8289,28271,29800,25970,8304,25970,27680,26721,25451,25970), .\n ' There are some who call me Tim?
RE: move rsync development tree to BitKeeper?
If you're serious about not using CVS (and I've used it, I understand why you might be :), may I suggest Perforce? It's a commercial product but it is free for use on open-source projects. The only complication would be you'd need to find a server to host it. I can say definitively that it ROCKS. TK -Original Message- From: Martin Pool [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 06, 2001 1:19 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Dave Dykstra Subject: move rsync development tree to BitKeeper? Andrew and I thought it might be an interesting experiment to move rsync to using BitKeeper rather than CVS for source code control.
unexplained error code when updating large (2G+) file
When trying to transfer a large file to another system in update mode (actually checking new build of 2.5.0 on HPUX 11.11, the file already exists but I was checking to see that rsync recognized that), I get: rsync error: unexplained error (code 130) at main.c(537) Any suggestions as to what and where the problem might be?
Problem: rsync hangs
Greetings, We've been experiencing intermittent timeout errors with rsync 2.4.x, but I've never been able to set up a small enough test case, nor track down the problem to its root cause[1]. Rsync 2.5.0 still has problems, but in a perverted way it's better: it's reproducible more quickly (1 hour, instead of many), and exhibits different symptoms: a hang, instead of a timeout. Here's the tail end of output from an instrumented version. This is from the server log: 2001/12/06 11:52:24 [24872] send_files: i=17187 (4323) 2001/12/06 11:52:24 [24872] send_files: (17187, /home/santiago/tmp/rsync-test/src-test/CVSROOT/eoi-log/62/20062) ...at this point, it hangs for a while, then every 10 minutes it blurts: 2001/12/06 12:02:24 [24872] rsync error: timeout in data send/receive (code 30) at io.c(77) 2001/12/06 12:12:24 [24872] rsync error: timeout in data send/receive (code 30) at io.c(77) 2001/12/06 12:22:24 [24872] rsync error: timeout in data send/receive (code 30) at io.c(77) 2001/12/06 12:32:24 [24872] rsync error: timeout in data send/receive (code 30) at io.c(77) 2001/12/06 12:42:24 [24872] rsync error: timeout in data send/receive (code 30) at io.c(77) The client side, meanwhile, is stuck at: 2001/12/06 11:57:27 [16232] CVSROOT/eoi-log/61/51361 2001/12/06 12:05:34 [16232] CVSROOT/eoi-log/61/51461 If I let it run for several hours, it seems to transfer one file per hour. At least, it appends filenames to the log at that rate. This goes on for 23 hours (the limit of my patience). FWIW, the 2.4.7 timeout happens under rsh, ssh, and rsyncd. I've only tested 2.5.0 under rsh, but have just started an ssh job to see if/when it hangs. 2.4.7 does consistently get farther along with ssh than with rsh. Typical # of files transfered before the hang is 3 to 4 thousand, but as you can see the above run did 17,000+. Invocation script is attached below. Has anyone seen this? Is there anything obvious I'm doing wrong? Any suggestions for how to track down the problem? Thanks in advance for any advice, ^E -- Ed Santiago Toolsmith [EMAIL PROTECTED] [1] root cause: the farthest I've been able to diagnose is that both client and server are stuck in select(), waiting to hear from each other. #!/bin/sh CMD=/home/santiago/src/rsync/rsync/rsync.solaris $CMD-z -avv --stats --delete --exclude=CVSROOT/history-old.gz \ --rsync-path=$CMD \ --timeout=600 \ --exclude=#cvs.rfl.* --exclude=#cvs.lock\ --exclude=CVSROOT/.#* --exclude=tools/a2ps/ \ --exclude=tools/binutils/ --exclude=tools/cvs/ \ --exclude=tools/egcs/ --exclude=tools/gcc/ \ --exclude=tools/gdb/ --exclude=tools/gnupro/\ --exclude=tools/perl/ --exclude=.repo-double-buffer.pid \ server-name:/home/santiago/tmp/rsync-test/src-test/CVSROOT ./results
Re: move rsync development tree to BitKeeper?
GNU Subversions is apparently now self-hosting (and is actually free, instead of arguably free :-) If you're looking at perforce or bitkeeper, though, also look at Accurev 3.0 (which is free-for-free-software, in java, *fast* and has a better consistency model...)
Re: rsync-2.5.1pre1 with -F option
Here's a better patch; rsync should now no longer dump core if called with
insufficient arguments. write_batch_argvs_file() is still ugly though, not
sure how to clean this up.
Index: batch.c
===
RCS file: /cvsroot/rsync/batch.c,v
retrieving revision 1.6
diff -u -r1.6 batch.c
--- batch.c 2 Dec 2001 22:47:30 - 1.6
+++ batch.c 6 Dec 2001 23:11:26 -
@@ -128,7 +128,7 @@
}
}
-void write_batch_argvs_file(int orig_argc, int argc, char **argv)
+void write_batch_argvs_file(int argc, char *argv[])
{
int fdb;
int i;
@@ -149,13 +149,17 @@
buff[0] = '\0';
/* Write argvs info to batch file */
- for (i = argc - orig_argc; i argc; i++) {
- /* FIXME: This apparently crashes if rsync is run with
-* just rsync -F. I think directly manipulating
-* argv[] is probably bogus -- what if -F is part of a
-* run of several short options? */
- if (!strcmp(argv[i], -F)) { /* safer to change it here than script
*/
- strncat(buff, -f , 3);/* chg to -f + ext to get
ready for remote */
+ for (i = 0; i argc; ++i) {
+ /*
+* FIXME: I think directly manipulating argv[] is probably
+* bogus -- what if -F is part of a run of several short
+* options?
+*/
+ if (!strcmp(argv[i], -F) ||
+ !strcmp(argv[i], --write-batch)) {
+ /* safer to change it here than script */
+ /* chg to -f + ext to get ready for remote */
+ strncat(buff, -f , 3);
strncat(buff, batch_file_ext,
strlen(batch_file_ext));
} else {
Index: main.c
===
RCS file: /cvsroot/rsync/main.c,v
retrieving revision 1.134
diff -u -r1.134 main.c
--- main.c 15 Aug 2001 07:50:07 - 1.134
+++ main.c 6 Dec 2001 23:11:27 -
@@ -765,8 +765,10 @@
extern int write_batch; /* dw */
extern char *batch_ext; /* dw */
int orig_argc; /* dw */
+ char **orig_argv;
orig_argc = argc; /* dw */
+ orig_argv = argv;
signal(SIGUSR1, sigusr1_handler);
signal(SIGUSR2, sigusr2_handler);
@@ -806,7 +808,7 @@
if (write_batch) { /* dw */
create_batch_file_ext();
- write_batch_argvs_file(orig_argc, argc, argv);
+ write_batch_argvs_file(orig_argc, orig_argv);
}
if (read_batch) { /* dw */
Index: proto.h
===
RCS file: /cvsroot/rsync/proto.h,v
retrieving revision 1.133
diff -u -r1.133 proto.h
--- proto.h 26 Nov 2001 07:18:09 - 1.133
+++ proto.h 6 Dec 2001 23:11:27 -
@@ -9,7 +9,7 @@
void write_batch_flist_file(char *buff, int bytes_to_write);
void write_batch_flist_info(int flist_count, struct file_struct **fptr);
void write_char_bufs(char *buf);
-void write_batch_argvs_file(int orig_argc, int argc, char **argv);
+void write_batch_argvs_file(int argc, char *argv[]);
struct file_list *create_flist_from_batch();
int read_batch_flist_file(char *buff, int len);
unsigned char read_batch_flags();
--
Jos Backus _/ _/_/_/Santa Clara, CA
_/ _/ _/
_/ _/_/_/
_/ _/ _/_/
[EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Cosmetic code cleanup?
Here's a list of cosmetic changes I'd be willing to make to the code in order to make it more consistent, which stylisticly it currently is not. - separate function definitions by 2 newlines - put spaces after commas in arg lists - put spaces around assignments - remove trailing spaces - change space indents to tabs - fix multiline comments - remove redundant /* dw */ comments (Deborah Weiss is already credited in the documentation) Thoughts? -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Stefan Stoerig/IDP/Muenchen/MAN_Nutzfahrzeuge istaußer Haus.
Ich werde ab 06.12.2001 nicht im Büro sein. Ich kehre zurück am 10.12.2001. Wenn Sie Fragen zu unserem Dokumentenserver haben, so schreiben Sie bitte eine Email an [EMAIL PROTECTED] . Mit freundlichen Grüßen, Stefan Störig
