ADSM-L

Re[2]: (U)Symbolic links in archives?

1998-09-10 14:11:16
Subject: Re[2]: (U)Symbolic links in archives?
From: Eric LEWIS <eric.lewis AT CCMAIL.ADP.WISC DOT EDU>
Date: Thu, 10 Sep 1998 12:11:16 -0600
     I don't know much about symbolic links but have been required to use
     them in our web-based ADSM registration and client distribution
     system.  The link points from the web page directory to the FTP
     directory where we put the "wrapped" client code that has our updates
     to the xxx.opt files.  We have a "button" on the client install web
     page that causes the client file to "FTP" to the client machine.

     To me they are just one more file.  If I backup the whole machine then
     the file and the symbolic link get backed up.  To do a bare-metal
     restore then certainly the links need to be treated as a file.  So the
     default should very definately be NO - don't follow the link.

     An OS device that can cause endless loops does not seem very well
     founded to me but I suppose now we got to live with it.

     Would this Followsymbolic=Yes/No apply to Windows shortcuts also?

     Eric Lewis U-Wis-Madison


______________________________ Reply Separator _________________________________
Subject: Re: (U)Symbolic links in archives?
Author:  <S.F.Westbroek AT h-w DOT nl > at IPNET
Date:    9/10/98 10:28 AM


Brian D Chase wrote:
>
> On Fri, 4 Sep 1998, Monte Ambrose wrote:
>
> > We are looking into re-doing the way ADSM handles symbolic links.  I
> > agree that it definitely needs changes.  Currently we are looking into
> > making ADSM consistent with the way it backs up symbolic links for
> > Archive and Backup.  One possible solution: Followsymbolic=yes will not
> > follow the link for both.  Followsymbolic=no will not follow the link
> > for both.  We do not like to add to many options but perhaps Archive and
> > Backup should have their own option for Followsymbolic.  Does anyone
> > have input into how this might affect them?  Currently if we follow a
> > link and it results in a looping situation we detect it and we end the
> > loop.  If you have a situation where you are getting into a loop because
> > of this then you should pursue through technical support because it is a
> > bug.
>
> I'd be most happy with Followsymbolic=yes having the behavior of following
> all symbolic links through to completion except in cases where a loop is
> detected.   And then with Followsymbolic=no, it would be nice if it'd
> archive the symbolic link as such and be able to retrieve it as a symbolic
> link.  At least coming from a predominantly Unix background, those types
> of behavior make the most sense to me.
>
> As the client is currently implemented, there definitely appears to be
> some buggy behavior.  The looped links I've happened across consistently
> result in the archive process running until either the scratch media is
> exhausted, or until the ever growing path names of the files associated
> with the link exceed some limit in the path name length. I'll put together
> some test cases and try them out with the latest clients for the Unix
> systems we have.
>
> -brian.


This is a known problem and I agree it should be reported and fixed. To
create a workaround (I can't remember the exact implementation) a
programmer in a previous project of my created a C program which looks
for symbolic links and based on a given parameter removed it before
starting the backup/archive. But before removing it, the symbolic link
is registered and saved in a log. Running the program with another
parameter restored all symbolic links that have been removed.

This way you keep track of all symbolic links and don't run into loops
etc.


--
Met vriendelijke groeten/ With kind regards,
Met vriendelijke groeten/ With kind regards,
Simon Westbroek,
H&W IT Services, tel.+31(35)525 8892
S.F.Westbroek AT h-w DOT nl