BackupPC-users

Re: [BackupPC-users] BackupPC and Windows junction points

2011-02-07 14:50:29
Subject: Re: [BackupPC-users] BackupPC and Windows junction points
From: "Jeffrey J. Kosowsky" <backuppc AT kosowsky DOT org>
To: "General list for user discussion, questions and support" <backuppc-users AT lists.sourceforge DOT net>
Date: Mon, 07 Feb 2011 14:48:51 -0500
John Rouillard wrote at about 19:02:11 +0000 on Monday, February 7, 2011:
 > On Mon, Feb 07, 2011 at 01:30:22PM -0500, Jeffrey J. Kosowsky wrote:
 > > There was a thread a little while back warning about junction point
 > > and Windows Vista/7. Also, the Wikki
 > > (http://sourceforge.net/apps/mediawiki/backuppc/index.php?title=Common_backup_excludes)
 > > talks about the need to exclude Junction points to avoid duplicate
 > > backup trees.
 > > 
 > > But it seems to me that at least when using cygwin rsync, that
 > > junction points are treated as symlinks so that there doesn't appear
 > > to be any duplication in backups.
 > > 
 > > The only issue may be in restoring in that cygwin rsync won't
 > > distinguish between true symlinks and junction points which are
 > > different animals in the Windows world.
 > > 
 > > Am I missing something?
 > 
 > I think so. The junction point isn't really treated as a symbolic
 > link. Rsync will back up a symbolic link as a link, it won't
 > dereference it (unless you ask it to). However a junction point grafts
 > the target location into the tree at that point and rsync merrily
 > continues to walk down and back up the grafted part of the tree. So
 > you have two copies of the files:
 > 
 >   1 the original location the junction point is pointing to
 >   2 the same files located under the junction point
 > 
 > Also your backups don't have a record of the junction point that rsync
 > traversed. When you restore the files you get two copies of the
 > grafted tree. One at each location.
 > 

What you say would seem logical based on the NTFS definition of
junction points which act more like hard links at a directory level
but it is not true at least in the cygwin/rsync world which tries to
translate NTFS into a POSIX-compatible world where apparently hard
linked directories don't exist. Indeed, *if* cygwin treated junction points as
directory *hard links* then they would appear as two different trees
that would be "merrily" traversed independently since rsync (and POSIX
in general) knows nothing about directory hard links.

HOWEVER, cygwin treats junction points just like symlinks -- indeed, I
don't even think it is possible within cygwin (at least using standard
*nix like file utilities) to tell the difference between a directory
symlink and a directory junction point. Thus cygwin rsync sees a
junction point as a symlink and by default doesn't follow and
dereference it so there is no duplicate tree walking -- that is true
according to the cygwin docs and I have also verified it manually.

Now the same might not be true for non-cygwin versions of rsync if
they interpret junction points more like hard links rather than
symlinks, but I have no experience with non-cgywin Rsync.

------------------------------------------------------------------------------
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world? 
http://p.sf.net/sfu/oracle-sfdevnlfb
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/