I tried a number of different settings for the file mask including
0700, 0600, 0500 and 0400. I also tried 0500 for the directory mask with each of these. To no avail.
However, I did figure out that it is the O_EXCL flag on the open() call that causes the problem. It is intended to make an open "exclusive" by atomically checking if the file exists and, if it does not, creating a new file. If this flag is omitted, rsync works with Sharity (albeit a small touch less securely).
Here is the recipe:
1. Download the source distribution of rsync.
2. Run the configure process.
3. Comment out the following line in config.h:
#define HAVE_SECURE_MKSTEMP 1
4. Patch the file syscall as follows:
# diff syscall.c.orig syscall.c
Add the following inside the do_mkstemp function (line 150):
int status;
Change the following line (at line 167):
return do_open(template, O_RDWR|O_EXCL|O_CREAT, perms);
to this:
status = do_open(template, O_RDWR|O_EXCL|O_CREAT, perms);
if ((status == -1) && (errno == EOPNOTSUPP))
status = do_open(template, O_RDWR|O_CREAT, perms);
return status;
This patch first tries to open the file exclusively and, if that fails because of the same incompatibility exhibited by Sharity, it tries without the exclusive flag.
If you could look into the possiblity of handling the O_EXCL flag in Sharity, it would be appreciated.
Sincerely,
David
----Original Message Follows----
From: Christian Starkjohann <[EMAIL PROTECTED]>
To: David Andrews <[EMAIL PROTECTED]>
CC: <[EMAIL PROTECTED]>
Subject: Re: [Sharity-talk] File corruption on Solaris
Date: Wed, 19 Feb 2003 19:22:06 +0100
On Wednesday, Feb 19, 2003, at 17:59 Europe/Vienna, David Andrews wrote:
Has anyone tried using "rsync" with Sharity? When I attempt to sync the mounts on two servers I receive the message:I assume that 'fpix' is a Sharity mount, right? The error message means that creating a temporary file failed. And it seems to indicate that the error occurred on the remote side (transport endpoint). The library function mkstemp() tries to set the temporary file to particular permissions (for security reasons). This may fail with Sharity because CIFS does not support the full range of Unix permissions. There is no real fix for this, but if you don't use Sharity for other purposes, you can set the faked permissions to what mkstemp() expects. That MIGHT help...
mkstemp fpix/.a.txt.jkaar0 failed: Operation not supported on transport endpoint
I bet this can be solved through a configuration change.
Christian,That's interesting. First, I don't understand why the setup process failed, but we had a similar report months ago. That person had a broken 'sed' utility installed. Restoring it from an other machine (I think) helped. Second, Sharity should not corrupt data whatever the configuration settings are. But on the other hand, it is hard to predict what happens when parameters are completely screwed...
I have fixed the problem. As it turns out the setup process failed and a number of % variables remained in the config file. I have manually set them and the strange behaviour has disappeared. Apologies for not noticing this sooner.
Regards, Christian.
--
Dipl.-Ing. Christian Starkjohann
Objective Development
mailto:[EMAIL PROTECTED] | http://www.obdev.at/
_______________________________________________
Sharity-talk mailing list
[EMAIL PROTECTED]
To unsubscribe see http://at.obdev.at/mailman/listinfo/sharity-talk
_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail
_______________________________________________
Sharity-talk mailing list
[EMAIL PROTECTED]
To unsubscribe see http://at.obdev.at/mailman/listinfo/sharity-talk
