Sélection et utilisation des propriétés des composants

L’utilisation de composants implicitement sélectionnés nécessite l’accès aux documents de métadonnées des composants de sauvegarde et de l’enregistreur.

Il existe deux raisons à cela :

• Les données de composant stockées dans le document composants de sauvegarde (représentées par l’interface IVssComponent ) n’ont pas accès aux informations du jeu de fichiers de composants ( spécification de fichier, chemin d’accès et indicateur de récursion). (Voir Utilisation du document des composants de sauvegarde.)
• Seuls les composants inclus explicitement dans le document Composants de sauvegarde pendant la sauvegarde ont leurs informations directement stockées dans le document Composants de sauvegarde. Les demandeurs et les rédacteurs doivent utiliser les informations disponibles via l’interface IVssComponent , conjointement avec les informations de chemin d’accès logique et les documents de métadonnées de l’enregistreur pour obtenir des informations sur les composants implicitement inclus et définir les propriétés des composants implicitement inclus.

Le cas « MyWriter » abordé dans Le chemin logique des composants peut être utilisé pour illustrer la sélection pour la sauvegarde.

Nom du composant	Chemin d’accès logique	Sélectionnable pour la sauvegarde	Sélectionnable pour la restauration	Inclus explicitement
« Exécutables »	""	N	N	O
« ConfigFiles »	« Exécutables »	N	N	O
« LicenseInfo »	""	O	N	O
« Security »	""	O	N	O
« UserInfo »	« Security »	N	N	N
« Certificats »	« Security »	N	N	N
« writerData »	""	O	O	O
« Set1 »	« writerData »	N	O	N
« Jan »	« writerData\Set1 »	N	N	N
« Déc »	« writerData\Set1 »	N	N	N
« Set2 »	« writerData »	N	O	N
« Jan »	« writerData\Set2 »	N	N	N
« Déc »	« writerData\Set2 »	N	N	N
« Requête »	« writerData\QueryLogs »	N	N	N
« Utilisation »	« writerData »	O	O	N
« Jan »	« writerData\Usage »	N	N	N
« Déc »	« writerData\Usage »	N	N	N

 

Composants implicitement inclus dans le jeu de sauvegarde

Lors de l’examen du document de métadonnées writer d’un rédacteur (voir IVssBackupComponents::GetWriterMetadata) pendant la sauvegarde, un demandeur doit stocker une liste de tous les composants, leurs chemins d’accès logiques et les informations de son jeu de fichiers.

Les informations sur le jeu de fichiers et les fichiers exclus sont nécessaires pour déterminer une liste de fichiers pour tout composant inclus (explicitement ou implicitement).

Pour les composants de sauvegarde non sélectionnables pour les ancêtres de sauvegarde et sélectionnables pour les composants de sauvegarde qui ne définissent pas un ensemble de composants, seules les informations sur les fichiers et les fichiers exclus sont nécessaires pour identifier tous les candidats à la sauvegarde du composant, car ces composants ne définissent pas de sous-composants.

Pour les éléments sélectionnables explicitement inclus pour les composants de sauvegarde qui définissent un ensemble de composants, les jeux de fichiers et les informations d’exclusion de fichier pour le composant de définition et tous les sous-composants doivent être utilisés pour sélectionner des fichiers à sauvegarder.

Cela signifie que les jeux de sauvegarde pour les composants « Exécutables », « ConfigFiles » et « LicenseInfo » ne peuvent être trouvés qu’en examinant les métadonnées de l’enregistreur pour ces composants uniquement à l’aide de leurs instances de l’interface IVssWMComponent .

Toutefois, si writerData est explicitement inclus dans la sauvegarde, vous devez examiner ses instance de l’interface IVssWMComponent et celles de « Set1 », « Jan » (avec le chemin logique « writerData\Set1 »), « Dec » (avec le chemin logique « writerData\Set1 »), « Set2 », « Jan » (avec le chemin logique « writerData\Set2 »), « Dec » (avec le chemin logique « writerData\Set2 »), « Query », « Usage », « Jan » (avec le chemin logique « writerData\Usage ») et « Dec » (avec le chemin logique « writerData\Usage »).

Pour ce faire, un demandeur doit d’abord identifier que le composant « writerData » (chemin logique « ») est sélectionnable. Il devra ensuite analyser tous les autres composants gérés par l’enregistreur pour déterminer si le premier élément de son chemin logique est « writerData ». Les composants qui ont « writerData » comme membres principaux de leur chemin logique sont identifiés comme étant des sous-composants de « writerData » et sont implicitement sélectionnés lorsqu’ils sont explicitement sélectionnés.

En fait, une analyse similaire doit être effectuée pour déterminer qu’aucun composant n’a « LicenseInfo » comme membre principal de son chemin logique, et donc que « LicenseInfo » n’a pas de sous-composants.

En raison de la complexité de ce mécanisme dans VSS, de nombreux rédacteurs demandeurs peuvent trouver utile de créer leurs propres structures pour stocker les informations sur les composants et les ensembles de sauvegarde pour les composants explicitement et implicitement ajoutés.

Propriétés des composants implicitement inclus

Pendant les opérations de restauration et de sauvegarde, les instances des interfaces IVssComponent et IVssBackupComponents sont utilisées à la fois pour récupérer des informations sur les composants et pour définir ou modifier les propriétés des composants. Toutefois, seuls les composants explicitement inclus auront des instances de l’interface IVssComponent ou seront accessibles à l’interface IVssBackupComponents .

Certaines propriétés sont définies à l’échelle du composant dans l’étendue. Ces propriétés sont les suivantes :

• Status de sauvegarde et de restauration :

IVssBackupComponents::SetBackupSucceededed
IVssComponent::GetBackupSucceeded
IVssBackupComponents::SetFileRestoreStatus
IVssComponent::GetFileRestoreStatus

• Options de sauvegarde et de restauration :

IVssBackupComponents::SetBackupOptions
IVssComponent::GetBackupOptions
IVssBackupComponents::SetRestoreOptions
IVssComponent::GetRestoreOptions

• Messages d’échec :

IVssComponent::SetPostRestoreFailureMsg
IVssComponent::SetPreRestoreFailureMsg
IVssComponent::SetPostRestoreFailureMsg
IVssComponent::SetPreRestoreFailureMsg

• Cibles de restauration :

IVssComponent::SetRestoreTarget
IVssComponent::GetRestoreTarget

• Empreintes de sauvegarde :

IVssComponent::SetBackupStamp
IVssComponent::GetBackupStamp

• Métadonnées supplémentaires :

IVssComponent::SetRestoreMetadata
IVssComponent::GetRestoreMetadata
IVssComponent::SetBackupMetadata
IVssComponent::GetBackupMetadata

Par conséquent, vous utilisez le instance de l’interface IVssComponent du membre de définition d’un jeu de composants ou utilisez le nom, le type et le chemin logique du membre définissant avec une méthode IVssBackupComponents pour définir ou récupérer des propriétés pour tous les membres du jeu de composants.

Pour cette raison, les jeux de composants sont traités comme des unités. Par instance, une sauvegarde d’un jeu de composants réussit uniquement si la sauvegarde de tous les jeux de fichiers de tous ses composants réussit.

Dans l’exemple précédent, supposons qu’un fichier du composant « Jan » (avec le chemin logique « writerData\Set2 ») est membre du jeu de composants défini par « writerData ». Si l’un des fichiers de « Jan » n’a pas pu être sauvegardé, un demandeur utilise les informations de « writerData » (son nom « writerData », son chemin d’accès « » et son type de composant) comme arguments lors de la définition d’IVssBackupComponents::SetBackupSucceed avecfalse pour indiquer l’échec du jeu de composants.

De même, l’état retourné par IVssComponent::GetBackupSucceed pour « writerData » instance de l’interface IVssComponent s’applique non seulement à « writerData », mais également à tous ses sous-composants.

En outre, si un rédacteur a choisi de modifier la cible de restauration à l’aide d’IVssComponent::SetRestoreTarget du instance de « writerData » d’IVssComponent, cela modifierait la cible de restauration pour tous les jeux de fichiers de tous les sous-composants de « writerData ».

Les propriétés suivantes ne s’appliquent pas à l’ensemble du composant, mais à des fichiers ou ensembles de fichiers particuliers :

• Mappages d’emplacements de remplacement :

IVssBackupComponents::AddAlternativeLocationMapping
IVssComponent::GetAlternateLocationMapping
IVssComponent::GetAlternateLocationMappingCount

• Fichiers différentiels :

IVssComponent::AddDifferencedFilesByLastModifyTime
IVssComponent::GetDifferencedFile
IVssComponent::GetDifferencedFilesCount

• Fichiers partiels :

IVssComponent::AddPartialFile
IVssComponent::GetPartialFile
IVssComponent::GetPartialFileCount

• Cibles dirigées :

IVssComponent::AddDirectedTarget
IVssComponent::GetDirectedTarget
IVssComponent::GetDirectedTargetCount

• Nouvelles cibles :

IVssBackupComponents::AddNewTarget
IVssComponent::GetNewTarget
IVssComponent::GetNewTargetCount

Lorsqu’un demandeur accède à ces fonctionnalités pour un sous-composant à l’aide de l’interface IVssBackupComponents , il utilise les informations de composant pour le composant de définition du jeu de composants, mais les informations de fichier ou de jeu de fichiers pour le sous-composant.

De même, si la propriété est accessible via l’interface IVssComponent, le instance correspondant au sous-composant de définition est utilisé, mais les arguments du fichier ou du jeu de fichiers sont extraits du sous-composant.

Par instance, supposons que le sous-composant « Jan » (avec le chemin logique « writerData\Set2 ») avait un jeu de fichiers avec un chemin d’accès « c:\fred », une spécification de fichier « *.dat » et qu’un indicateur récursif de true puisse devoir être restauré à un autre emplacement.

Dans ce cas, un demandeur appelle IVssBackupComponents::AddAlternativeLocationMapping, en utilisant les informations de « writerData » (type de composant, nom de composant « writeData » et chemin logique « ») ainsi que les informations de jeu de fichiers de « Jan » (chemin d’accès « c:\fred », spécification de fichier « *.dat », et la récursion est égale à true).

Notez que dans ce cas, les informations du jeu de fichiers doivent correspondre exactement aux informations de jeu de fichiers utilisées par IVssCreateWriterMetadata::AddFilesToFileGroup, IVssCreateWriterMetadata::AddDatabaseFiles, ou IVssCreateWriterMetadata::AddDatabaseLogFiles pour ajouter des fichiers à Jan.

De même, si un rédacteur voulait ajouter une cible dirigée à un fichier avec le chemin d’accès « c:\ethel » et le nom « lucy.dat » géré par « Jan » (avec le chemin logique « writerData\Set2 »), il utiliserait le instance IVssComponent correspondant à « writerData », mais les informations de fichier « Jan ».

Composants implicitement inclus dans l’ensemble de restauration

Les composants qui ont été implicitement inclus dans une sauvegarde peuvent être inclus explicitement dans une restauration s’ils peuvent être sélectionnés pour la restauration. Comme indiqué dans Utilisation de la fonctionnalité de sélection pour la restauration et les sous-composants, ces composants sont ajoutés au document composants de sauvegarde à l’aide de la méthode IVssBackupComponents::AddRestoreSubcomponent.

Toutefois, cela ne crée pas de instance de l’interface IVssComponent, et le composant n’est pas directement accessible via l’interface IVssBackupComponents.

Au lieu de cela, un composant explicitement inclus pour la restauration, mais implicitement inclus pour la sauvegarde, doit être accessible via une instance de l’interface IVssComponent correspondant au composant qui a défini l’ensemble de composants dont il était membre lors de la sauvegarde.

Par exemple, pour inclure explicitement pour la restauration « Set1 », un sous-composant du composant sélectionnable pour la sauvegarde « writerData », vous obtiendrez des informations à ce sujet en appelant la méthode IVssComponent::GetRestoreSubcomponent du instance de l’interface IVssComponent.