Thanks for the feedback.

We were doing archives with the -delete option so could work around it by
modifying our script to  move the file to the /temp directory and archive
it from their with a note in the description of where it actually came
from.

Would be nice if it could be fixed so the archive could be done from the
original location - will hope it's an easy fix :-).

We were doing the archive of many files as root user when we experienced
this behaviour, so it looks like your first suggestion doesn't work - at
least for the archive command.

...Chris

At 11:27 AM 11/28/95 -0800, Mj Lopatin wrote:
>Yesterday, Chris Krusch wrote about his ADSM Solaris V2 client:
>
>> I'm attempting an archive of a single file in the
>> /var/mail directory using:
>>    archive /var/mail/testfile
>
>> The archive client seems to lock up after archive
>> processing is invoked.  The command works fine
>> if we chose a file in a much smaller directory, such as
>>     archive /tmp/testfile
>
>> P.S. Out of curiousity we also tried it with a version 1.2 client
>> with the same results.
>
>Chris,
>
>  We just recently detected similar behavior in our internal testing,
>using SELECTIVE (we don't see it with INCREMENTAL) to backup a few
>files from very large filesystems on UNIX clients.  We are currently
>investigating why we are only now detecting this behavior, when
>as you noticed, the code in this area has not been changed
>since Version 1.
>
>  Two workarounds we have found:
>1) Backing up the file as root user, or
>2) Creating a virtual mountpoint for that directory to reduce the
>size of the effective filesystem
>
>  We have two strategies:
>1) We are looking for a short-term fix.  If there was a recent
>client or server code change that allowed this behavior to
>suddenly show up, and we can easily redo that change, we will.
>However, the basic code which has been there since Version 1
>cannot be easily or quickly changed.
>2) More long-term, we want to restructure some of our client code and
>the way we perform some of our client commands in a future release,
>which would solve the problem at its root cause.
>
>Meanwhile, please try the workarounds.
>
>  -- MJ Lopatin
>     ADSM Client Development

Chris Krusch                             Email: Chris.Krusch AT ubc DOT ca
University Computing Services            Phone: (604)822-4215