I suspect that I've found the problem. It appears that the permissions for
these directories have been turned off at some point for these directories.
This might be causing the problem with --link-dest. When it tried to stat
the file on the backup it couldn't and therefore did not exist. Although,
you would expect if you ignored owner, group, and perms that it would just
default to those permissions on the target volume.
d---------+ 1 nancy None 0 Jul 8 2013 0313BookshelvesCSD
drwx------+ 1 nancy None 0 Dec 27 2013 0413SpringChorusCSD
d---------+ 1 nancy None 0 Jul 8 2013 0513CapeCodCSD
-rwx------ 1 nancy None 114309469 Nov 13 2013 0612BonAppetitCSD.zip
-rwx------ 1 nancy None 85356572 Nov 13 2013 0612BonAppetitCSD_QDDL.zip
-rwx------ 1 nancy None 5893538 Nov 13 2013
0612BonAppetitCSD_Templates.zip
d---------+ 1 nancy None 0 Jul 8 2013 0613HopesCSD
drwx------+ 1 nancy None 0 Dec 27 2013 0913TakeWingCSD
drwx------+ 1 nancy None 0 Dec 27 2013 1013LockKeyCSD
Thanks,
-Clint
On Sat, Jan 10, 2015 at 6:19 PM, Kevin Korb <kmk at sanitarium.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> If it seeing the files as new then I agree that stat won't help. It
> might have explained some other itemize output. Since it is seeing
> the files as new then they must not be where it is looking. Meaning
> that your link-dest parameter must not be appropriate for your target.
>
> On 01/10/2015 08:49 PM, Clint Olsen wrote:
> > On Sat Jan 10 2015 at 5:21:33 AM Kevin Korb <kmk at sanitarium.net
> > <mailto:kmk at sanitarium.net>> wrote:
> >
> > -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >
> > What does --itemize-changes say about that file? Try using the
> > stat command on the various copies of it to see what is different
> > about them.
> >
> >
> > In my original message, I stated I used --itemize-changes, and I
> > reported the following:
> >
> >> <f+++++++++ nancy/Documents/SCRAPPING/__Digital/Club
> >> Scrap/0313BookshelvesCSD/__0313BookshelvesCSD.zip
> >
> > Are there other debug switches I should consider? I don't see why
> > stat'ing the file will matter considering that rsync thinks this
> > file is new.
> >
> >> When I run with a command like the following:
> >>
> >> /usr/bin/rsync -avz /--itemize-changes /--dry-run --no-o --no-g
> >> --no-p --exclude-from=/cygdrive/c/__Users/clint/.rsync/exclude
> >> --delete --delete-excluded --link-dest=../latest
> >> /cygdrive/c/Users/clint /cygdrive/c/Users/nancy
> >> rsync at nas::NetBackup/sith/__2015-01-09T11_58_16
> >>
> >>
> >> Rsync comes back and tells me this:
> >>
> >> <f+++++++++ nancy/Documents/SCRAPPING/__Digital/Club
> >> Scrap/0313BookshelvesCSD/__0313BookshelvesCSD.zip
> >
> >
> > Thanks,
> >
> > -Clint
>
> - --
>
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
> Kevin Korb Phone: (407) 252-6853
> Systems Administrator Internet:
> FutureQuest, Inc. Kevin at FutureQuest.net (work)
> Orlando, Florida kmk at sanitarium.net (personal)
> Web page: http://www.sanitarium.net/
> PGP public key available on web site.
>
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iEYEARECAAYFAlSx3cgACgkQVKC1jlbQAQf0UACg2XQS42aTwLPv0xbEmQQalbDL
> TEQAoOTSbhtM4p3wj/nrxROoy85O1GRa
> =lB3o
> -----END PGP SIGNATURE-----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.samba.org/pipermail/rsync/attachments/20150111/af085d9e/attachment.html>