Hi Ginnie,
On Mon, 10 Jan 2011, Ginnie Wray wrote:
Hi Darren and Keith...
See below.
On 01/10/11 06:42, Darren Kenny wrote:
On 06/01/2011 19:40, Keith Mitchell wrote:
On 01/ 6/11 12:30 PM, Ginnie Wray wrote:
Hi -
I have some observations that I would like to get some feedback on
regarding this bug.
First observation: Transfer makes an assumption about the state that the
build area will be in. It makes choices based on whether the source
directory exists in the data set. If the source directory exists,
Transfer assumes that it is ok to begin a transfer. In the case of this
CR, the source directory did exist but there was nothing within the
directory to permit a transfer to continue. Since the data set was in an
indeterminate state, the transfer failed.
The key is that it made assumptions about the state of the directory, even
though there's no guarantee that it is the *next* checkpoint being run -
which means there's no guarantee that the state of the directory will be
changed by a checkpoint that runs prior to it. I don't think that the
__init__ of a checkpoint, and any functions it calls, should make
assumptions about any pre-conditions of the DOC, build area, etc.
Totally agree with this - because of the way that __init__ is done early,
but
the actual execution doesn't happen until later in the cycle - nothing
really
can be guaranteed until the call to execute() - it is only at this point
that
you can safely assume that things should be inplace for the checkpoint to
run.
The code I'm referring to isn't part of the __init__. This is code that is
used by transfer's get_progress_estimate, which is called by the engine after
the transfer checkpoint is loaded (that is when __init__ is executed).
My question is, does there need to be a delineation between providing an
estimate during the period when nothing is guaranteed and when it is? I think
for the transfer checkpoint, this makes a difference. When nothing is
guaranteed, transfer could return a default value. Right now, there isn't a
way for transfer to know definitively what to do.
As part of a bigger scenario, for any given transfer, a requested file or
directory might not exist in the source area. (As was the case in this
instance). DC folks requested that transfer ignore missing files and report
the error output in the log. Would this be true for all applications, or
should the application be able to choose how that's handled?
After dealing with a couple of issue as a result of the missing
files, I'm of the opinion that transfer should actually abort
processing if it fails to transfer one or more of the specified
files.
See the following CR:
7010088 transfer-cpio should abort when a file to be transferred is not found
Alok
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
