All, Has anyone tried using "rsync" with Sharity? When I attempt to sync the mounts on two servers I receive the message:
mkstemp fpix/.a.txt.jkaar0 failed: Operation not supported on transport endpoint I bet this can be solved through a configuration change. Christian, 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. David > > From: Christian Starkjohann <[EMAIL PROTECTED]> > Date: 2003/02/19 Wed AM 05:35:58 EST > To: [EMAIL PROTECTED] > CC: [EMAIL PROTECTED] > Subject: Re: [Sharity-talk] File corruption on Solaris > > On Tuesday, Feb 18, 2003, at 23:34 Europe/Vienna, David Andrews wrote: > > Thanks Mike, > > > > I think this is similar. Here is an example from the Solaris side: > > # sum -r /mount/AMM001 > > 38207 4257 /mount/AMM001 > > # cp /mount/AMM001 /tmp > > # sum -r /tmp/AMM001 > > 38207 4257 /tmp/AMM001 > > # cp /tmp/AMM001 /mount/AMMxxx > > # sum -r /mount/AMM001 > > 42616 4257 /mount/AMM001 (***!!!!!!!***) > > # sum -r /tmp/AMM001 > > 38207 4257 /tmp/AMM001 > > > > What has happened above is that the original checksum on the original > > file is reporting a false value (the checksum of a corruption). The > > file that's stored in /tmp is also corrupted in the same way (and > > therefore has the same checksum). When the filesystem is fooled with > > (by storing the already-corrupted /tmp file into AMMxxx) the > > corruption changes and therefore the original file appears to have > > changed. > > > > I wonder if the reported 42616 is the correct checksum. If so, it > > would match your results. Are your files very large? This file is only > > about 2MB. > > It seems I have not received the mail you replied to. File corruption > is a very serious problem and we don't have an open bug report > involving such a problem. If anyone gets corrupted data through > Sharity, PLEASE REPORT THIS PROBLEM! > > David: To find out what's going on, we should try to get a more > controlled environment. Can you please do the following: > > 1. Get a test file which reproduces the problem. > 2. Transfer the file to the server by other means (ftp, floppy disk or > whatever). > 3. Read it through Sharity and compare with the original. > > If the files don't match, please run GNU diff to see where the content > has changed. Or run at least 'cmp' (maybe with option '-l') to see the > offset of the corruption. > > It is possible that the corruption only occurs with particular > programs. You can also try running cmp directly between the Sharity > mounted file and the original, or use 'cp' to copy the mounted file to > /tmp and compare it there. This may make a difference. > > Regards, Christian. > > PS: Is this with the NFS2 or NFS3 frontend? Does it make a difference > if you use the other? > > -- > 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
