AnglaisFrançaisEspagnol

Ad


Icône de favori OnWorks

wimcapture - En ligne dans le Cloud

Exécutez wimcapture dans le fournisseur d'hébergement gratuit OnWorks sur Ubuntu Online, Fedora Online, l'émulateur en ligne Windows ou l'émulateur en ligne MAC OS

Il s'agit de la commande wimcapture qui peut être exécutée dans le fournisseur d'hébergement gratuit OnWorks en utilisant l'un de nos multiples postes de travail en ligne gratuits tels que Ubuntu Online, Fedora Online, l'émulateur en ligne Windows ou l'émulateur en ligne MAC OS

PROGRAMME:

Nom


wimlib-imagex-capture, wimlib-imagex-append - Créer ou ajouter une image WIM

SYNOPSIS


wimlib-imagex capturer SOURCE FICHIER WIMF [IMAGE_NAME [DESCRIPTION DE L'IMAGE]] [OPTION...]
wimlib-imagex ajouter SOURCE FICHIER WIMF [IMAGE_NAME [DESCRIPTION DE L'IMAGE]] [OPTION...]

DESCRIPTION


La wimlib-imagex capturer ainsi que wimlib-imagex ajouter les commandes créent une image Windows (WIM)
image d'une arborescence de répertoires. Les wimlib-imagex capturer la commande crée un nouveau fichier WIM
contenant l'image capturée, tandis que le wimlib-imagex ajouter la commande ajoute le capturé
image dans un fichier WIM existant. Ces commandes sont également disponibles simplement wimcapture ainsi que
wimpend si les liens physiques ou les fichiers batch appropriés sont installés.

Informations générales : Une image WIM est une arborescence de répertoires indépendante dans un fichier WIM. Un WIM
Le fichier peut contenir n'importe quel nombre d'images séparées. Les fichiers WIM sont à instance unique avec
en ce qui concerne les données de fichier, de sorte qu'un fichier n'est stocké qu'une seule fois dans l'ensemble du WIM, indépendamment de
dans combien d'images le fichier apparaît.

SOURCE spécifie l'emplacement des fichiers à partir desquels créer la nouvelle image WIM. Si SOURCE is
un répertoire, l'image WIM est capturée à partir de ce répertoire (voir ANNUAIRE CAPTURER (UNIX)
or ANNUAIRE CAPTURER (LES FENÊTRES)). Alternativement, si le --Liste des sources option est
spécifié, SOURCE est interprété comme un fichier qui fournit lui-même une liste de fichiers et
répertoires à inclure dans la nouvelle image WIM. Toujours alternativement, uniquement sur UNIX-like
systèmes, si SOURCE est un fichier ou un périphérique de bloc normal, il est interprété comme un volume NTFS
à partir de laquelle une image WIM doit être capturée à l'aide de libntfs-3g (voir NTFS LE VOLUME CAPTURER
(UNIX)).

IMAGE_NAME ainsi que DESCRIPTION DE L'IMAGE spécifier le nom et la description à donner au nouveau WIM
image. Si IMAGE_NAME n'est pas spécifié, il s'agit par défaut du nom de base (à l'exception du chemin vers
répertoire parent) de SOURCE, mais si ce nom existe déjà dans FICHIER WIMF, un suffixe unique
est ajouté. Autrement, IMAGE_NAME doit être soit un nom qui n'existe pas déjà en tant que
image dans FICHIER WIMF, ou la chaîne vide pour créer une image sans nom. Si
DESCRIPTION DE L'IMAGE n'est pas spécifié, aucune description n'est donnée à la nouvelle image.

Comme cas particulier, si FICHIER WIMF est le --pipable l'option est supposée et le fichier WIM est
écrit sur la sortie standard dans un format pipable spécial. Voir la documentation pour
--pipable pour plus de détails.

ANNUAIRE CAPTURER (UNIX)


Cette section documente comment wimlib-imagex capture les fichiers d'une arborescence de répertoires sous UNIX
systèmes. Voir ANNUAIRE CAPTURER (LES FENÊTRES) pour la documentation correspondante pour Windows.

Sur les systèmes de type UNIX, lorsque SOURCE spécifie un répertoire ou un lien symbolique vers un répertoire,
l'image WIM sera capturée à partir de l'arborescence de répertoires enracinée dans ce répertoire. Cette
peut se trouver sur n'importe quel type de système de fichiers et les points de montage sont suivis de manière récursive. Dans
ce mode, wimlib stockera les types d'informations suivants :

· Les répertoires et fichiers normaux, et le contenu des fichiers normaux

· Liens physiques

· Liens symboliques (traduits sans perte en points d'analyse Windows)

· Heures de dernière modification (mtime) et dernières heures d'accès (atime) avec 100 nanosecondes
granularité

· Avec --unix-données: propriétaires, groupes et modes UNIX

· Avec --unix-données: nœuds de périphérique, FIFO et sockets de domaine UNIX

Il n'y a pas de support pour le stockage d'attributs étendus (par exemple les étiquettes de sécurité SELinux et
ACL POSIX). Notez également que les heures de dernier changement d'état (ctime) ne sont pas stockées.

Note pédante : Une limitation du format WIM évite le cas inhabituel où un seul
le fichier de lien symbolique lui-même a plusieurs noms (liens physiques) ; dans ce cas improbable, chaque
le lien symbolique est stocké dans un fichier indépendant.

NTFS LE VOLUME CAPTURER (UNIX)


Cette section documente comment wimlib-imagex capture des fichiers directement à partir d'une image de volume NTFS
sur des systèmes de type UNIX.

Sur les systèmes de type UNIX, un mode de capture d'image spécial est activé lorsque SOURCE est un habitué
fichier ou bloc de périphérique. Dans ce mode, SOURCE est supposé être un volume ou un volume NTFS
image, et wimlib-imagex capturera une image WIM contenant le contenu complet du NTFS
volume, y compris les données spécifiques à NTFS. Ceci est fait en utilisant libntfs-3g.

Notez que le mode de capture de volume NTFS est ne sauraient entré si SOURCE est un répertoire, même si un
Le système de fichiers NTFS est monté sur SOURCE en utilisant ntfs-3g. Vous devez spécifier le volume NTFS
lui-même (et il doit être démonté, et vous devez avoir la permission de le lire).

Le mode de capture de volume NTFS tente de capturer autant de données et de métadonnées que possible,
comprenant:

· Tous les flux de données de tous les fichiers non cryptés, y compris le flux de données sans nom
comme tous les flux de données nommés.

· Points d'analyse, y compris les liens symboliques, les points de jonction et autres points d'analyse.

· Horodatages de création, d'accès et de modification de fichiers et de répertoires, en utilisant le natif
Résolution NTFS de 100 nanosecondes.

· Descripteurs de sécurité Windows, y compris tous les composants (propriétaire, groupe, DACL et SACL).

· Indicateurs d'attribut de fichier DOS/Windows.

· Tous les noms de tous les fichiers, y compris les noms dans l'espace de noms Win32, l'espace de noms DOS,
Espace de noms Win32+DOS et espace de noms POSIX. Cela inclut les liens physiques.

Cependant, les principales limitations de ce mode de capture de volume NTFS sont :

· Les fichiers cryptés sont exclus par défaut. Bien que libntfs-3g puisse lire leurs données,
ils doivent être stockés dans le fichier WIM dans un format spécial que wimlib n'a pas encore
support (sauf sous Windows, où wimlib peut traiter les données comme opaques et les transmettre
à la fonction API appropriée).

· L'attribut sparse sur les fichiers sparse sera enregistré, mais les données stockées seront les
données complètes du fichier plutôt que les données « clairsemées ». (Les données sont toutefois soumises
à la compression du format WIM.)

ANNUAIRE CAPTURER (LES FENÊTRES)


Sur Windows, wimlib-imagex capturer ainsi que wimlib-imagex ajouter prend en charge nativement Windows-
données spécifiques et spécifiques à NTFS. Ils agissent donc de la même manière que les correspondants
commandes de Microsoft ImageX ou DISM. Pour de meilleurs résultats, le répertoire en cours de capture
doit être sur un volume NTFS et wimlib-imagex doit être exécuté avec des privilèges d'administrateur ;
cependant, les systèmes de fichiers non NTFS et s'exécutant sans privilèges d'administrateur sont également
prise en charge.

Sur Windows, wimlib-imagex capturer ainsi que wimlib-imagex ajouter essayez d'archiver autant de données et
métadonnées que possible, y compris :

· Tous les flux de données de tous les fichiers.

· Points d'analyse, y compris les liens symboliques, les points de jonction et autres points d'analyse,
si pris en charge par le système de fichiers source. (Remarque : voir --rpfix ainsi que --norpfix en
documentation sur la manière exacte dont les liens et les jonctions symboliques absolus sont capturés.)

· Horodatages de création, d'accès et de modification de fichiers et de répertoires. Ceux-ci sont stockés
avec la résolution d'horodatage native de Windows NT de 100 nanosecondes.

· Descripteurs de sécurité, s'ils sont pris en charge par le système de fichiers source et --pas d'acls n'est pas
spécifié. Cependant, sachez qu'à moins --strict-acls est spécifié, la sécurité
les descripteurs de fichiers ou de répertoires individuels peuvent être omis ou seulement partiellement
capturés si l'utilisateur n'a pas la permission de les lire, ce qui peut être un problème si
wimlib-imagex est exécuté en tant que non-administrateur.

· Attributs de fichier, y compris caché, clairsemé, compressé, crypté, etc. Crypté
les fichiers seront stockés sous forme cryptée plutôt qu'en texte brut. En toute transparence
les fichiers compressés seront lus comme non compressés et stockés sous réserve des propres WIM
compression. Il n'y a pas de traitement spécial pour le stockage des fichiers fragmentés, mais ils sont
susceptible de se comprimer à une petite taille.

· Noms DOS (8.3) noms de fichiers ; cependant, le fait de ne pas les lire n'est pas considéré comme un
condition d'erreur.

· Liens physiques, s'ils sont pris en charge par le système de fichiers source.

Il n'y a pas de prise en charge du stockage des attributs étendus NTFS et des ID d'objet.

Le processus de capture est réversible, car quand wimlib-imagex vous inscrire (sous Windows) extraits
l'image WIM capturée, il extraira toutes les informations ci-dessus, au moins jusqu'au
étendue supportée par le système de fichiers de destination.

Note pédante : puisque Windows n'est pas entièrement compatible avec son propre système de fichiers (NTFS), sur
Windows wimlib ne peut pas archiver certains fichiers qui peuvent exister sur un système de fichiers NTFS valide mais
sont inaccessibles à l'API Windows, par exemple deux fichiers dont les noms ne diffèrent que par
cas dans le même répertoire, ou un fichier dont le nom contient certains caractères considérés
invalide par Windows. Si vous rencontrez des problèmes pour archiver de tels fichiers, envisagez d'utiliser le NTFS
LE VOLUME CAPTURER (UNIX) mode de Linux.

OPTIONS


--botte
Spécifie que la nouvelle image doit devenir l'image amorçable de l'archive WIM.

--Chèque
Pour wimlib-imagex ajouter, avant d'effectuer l'opération d'ajout, vérifiez le
intégrité de FICHIER WIMF si une table d'intégrité est présente. De plus, incluez un
table d'intégrité dans le nouveau fichier WIM (wimlib-imagex capturer) ou le fichier WIM modifié
(wimlib-imagex ajouter). Si cette option n'est pas spécifiée, aucune table d'intégrité n'est
inclus dans un fichier WIM créé avec wimlib-imagex capturer, tandis qu'un fichier WIM est mis à jour
avec wimlib-imagex ajouter sera écrit avec une table d'intégrité si et seulement si une
était présent auparavant.

--compresse=TYPE[:NIVEAU]
Spécifie le format de compression pour le nouveau fichier WIM. TYPE peut être "aucun", "XPRESS"
(alias : "rapide"), "LZX" (alias : "maximum"), ou "LZMS" (alias : "recovery"). TYPE is
mis en correspondance sans tenir compte de la casse. La valeur par défaut est "LZX".

Vous pouvez également spécifier une compression d'entier NIVEAU. Le niveau de compression
spécifie la dureté de l'algorithme de compression pour la compression spécifiée TYPE sera
travailler pour compresser les données. Les valeurs sont mises à l'échelle de manière à ce que 20 corresponde à une compression rapide,
50 correspond à une compression moyenne et 100 à une compression élevée. Cependant, vous pouvez choisir n'importe quel
valeur, et pas seulement ces valeurs particulières. La valeur par défaut est 50.

Cette option affecte uniquement le type de compression utilisé dans les ressources WIM non solides. Si
vous créez un WIM solide (en utilisant le --solide option), alors vous voudrez probablement
--solide-compresser à la place.

Soyez prudent si vous choisissez la compression LZMS. Il n'est pas compatible avec wimlib avant
v1.6.0, WIMGAPI avant Windows 8, DISM avant Windows 8.1 et 7-Zip avant v15.12.

Notez également que le choix de la compression LZMS n'implique pas automatiquement le mode solide
compression, comme c'est le cas avec DISM. Utilisation --solide si vous voulez créer un WIM solide,
ou "Fichier ESD".

--chunk-taille=TAILLE
Réglez la taille du bloc de compression sur TAILLE octets. Une plus grande taille de bloc de compression
donne un meilleur taux de compression. wimlib prend en charge différentes tailles de morceaux
selon le type de compression :

· XPRESS : 4K, 8K, 16K, 32K, 64K

· LZX : 32K, 64K, 128K, 256K, 512K, 1M, 2M

· LZMS : 32K, 64K, 128K, 256K, 512K, 1M, 2M, 4M, 8M, 16M, 32M, 64M, 128M, 256M, 512M,
1G

Vous pouvez fournir le numéro complet (par exemple 32768), ou vous pouvez utiliser l'un des K, M ou G
suffixes. KiB, MiB et GiB sont également acceptés.

Cette option affecte uniquement la taille de segment utilisée dans les ressources WIM non solides. Si vous êtes
créer un WIM solide (en utilisant le --solide option), alors vous voudrez probablement --solide-
taille de morceau à la place.

Utilisez cette option avec prudence si la compatibilité avec l'implémentation de Microsoft est
souhaité, car leur implémentation a une prise en charge limitée des tailles de blocs autres que celles par défaut.

--solide
Créez un fichier WIM "solide" qui compresse les fichiers ensemble plutôt qu'indépendamment.
Cela se traduit par un taux de compression nettement meilleur, mais cela se fait au prix
de divers compromis, notamment : une compression lente avec une utilisation très élevée de la mémoire ; lent
accès aléatoire au fichier WIM résultant ; et une compatibilité réduite.

Du point de vue de la compatibilité, la première version de WIMGAPI de Microsoft à prendre en charge un WIM solide
fichiers a été publié avec Windows 8, et la première version de DISM à le faire était
publié avec Windows 8.1.

Si vous souhaitez créer un "fichier ESD", utilisez cette option. Un (non crypté) "ESD
file" est un fichier WIM solide.

Par défaut, cette option a un effet équivalent à l'option de DISM
/compresser:récupération. Les options pour wimlib-imagex sont différentes car elles essaient
ne pas confondre le type de compression (par exemple LZX ou LZMS) avec la compression en mode solide,
car ce sont deux choses différentes.

--solid-morceau-taille=TAILLE
Comme --chunk-taille, mais définissez la taille du morceau utilisé dans les ressources solides. Le défaut,
en supposant que la compression LZMS est de 64 Mio (67108864) ; cela nécessite environ 640 Mo de mémoire
par fil. Cette option n'a d'effet que lorsque --solide est également précisé. Noter:
L'implémentation de Microsoft n'est pas compatible avec les tailles de blocs LZMS supérieures à
64 Mio.

--solide-compresser=TYPE[:NIVEAU]
Comme --compresse, mais définissez le type de compression utilisé dans les ressources solides. Le défaut
est la compression LZMS. Cette option n'a d'effet que lorsque --solide est également précisé.

--threads=NUM_THREADS
Nombre de threads à utiliser pour compresser les données. Par défaut : détection automatique (nombre de
processeurs disponibles).

--reconstruire
Pour wimlib-imagex ajouter: reconstruire l'intégralité du WIM plutôt que d'ajouter les nouvelles données
jusqu'au bout. La reconstruction du WIM est plus lente, mais permettra d'économiser un peu d'espace
qui serait autrement laissé comme un trou dans le WIM. Regarde aussi wimlib-imagex
optimiser (1).

--drapeaux=ID D'ÉDITION
Spécifiez une chaîne à utiliser dans le élément des données XML pour la nouvelle image.

--image-propriété Nom=VALEURE
Spécifiez une propriété arbitraire par image à définir dans le document XML du fichier WIM.
VALEURE est la chaîne à définir comme valeur de propriété. Nom est le nom de l'image
propriété, par exemple « NAME », « DESCRIPTION » ou « TOTALBYTES ». Le nom peut contenir
des barres obliques pour indiquer un élément XML imbriqué ; par exemple,
"WINDOWS/VERSION/BUILD" indique l'élément BUILD imbriqué dans la VERSION
élément imbriqué dans l'élément WINDOWS. Un nombre entre parenthèses peut être utilisé pour
indiquer l'un des éléments portant le même nom ; par exemple,
"WINDOWS/LANGUAGES/LANGUAGE[2]" indique le deuxième élément "LANGUAGE" imbriqué
dans l'élément "WINDOWS/LANGUAGES". Lors de l'ajout d'une liste d'éléments de cette manière,
ils doivent être spécifiés dans l'ordre séquentiel. Notez que les noms d'éléments sont en casse
sensible. Cette option peut être spécifiée plusieurs fois.

--déréférencement
(Systèmes de type UNIX uniquement) Suivez les liens symboliques et archivez les fichiers vers lesquels ils pointent,
plutôt que d'archiver les liens eux-mêmes.

--config=DOSSIER
Spécifie un fichier de configuration (encodé en UTF-8 ou UTF-16LE ; l'ASCII simple fonctionne également)
pour capturer la nouvelle image. Le fichier de configuration spécifie les fichiers qui doivent être
traités spécialement lors de la capture de l'image.

Le format du fichier de configuration est de style INI ; c'est-à-dire qu'il est disposé en
sections entre crochets. Actuellement, les sections suivantes sont reconnues :

· [ExclusionList] --- contient une liste de chemins d'accès à exclure de la capture. Si
un répertoire est mis en correspondance, le répertoire et son contenu sont exclus.

· [ExclusionException] --- contient une liste de chemins d'accès à inclure dans le
capture, même lorsque le fichier ou le répertoire correspond également à un glob dans [ExclusionList].

· [PrepopulateList] --- cela n'affecte pas la capture, mais si l'image est appliquée
plus tard avec --wimboot, ce sont des globs de fichiers qui doivent être extraits normalement,
pas en tant que "fichiers pointeurs" WIMBoot. Si un répertoire correspond, tous les fichiers et
les sous-répertoires sont également appariés de manière récursive.

Les globs de chemin peuvent contenir le '*' et '?' méta-caractères. Globules relatives (par exemple
*.mp3) correspond à un nom de fichier dans n'importe quel répertoire. Les globs absolus (par exemple /dir/file),
sont traités comme des chemins commençant au répertoire principal en cours de capture, ou à la racine de
le volume NTFS pour le mode de capture de volume NTFS. N'utilisez pas de lettres de lecteur dans le
chemins; ils seront ignorés. Les séparateurs de chemin peuvent être des barres obliques ou
barres obliques inverses.

Les lignes commençant par le '#' ou ';' les caractères sont traités comme des commentaires et ignorés.
Les globs contenant des espaces n'ont pas besoin d'être cités ; cependant, s'ils le sont, les deux doublent
et les guillemets simples sont acceptés.

Si cette option n'est pas spécifiée, le fichier de configuration par défaut suivant est utilisé :

[Liste d'exclusion]
\$ntfs.log
\hiberfil.sys
\pagefile.sys
\fichierd'échange.sys
\Information de volume du system
\RECYCLEUR
\Windows\CSC

Cependant, un comportement spécial s'applique si --wimboot est également précisé. Par défaut, avec
--wimboot spécifié, le fichier Windows/System32/WimBootCompress.ini dans le répertoire
en cours de capture sera utilisé comme fichier de configuration. Cependant, cela peut être
outrepassé à l'aide --config; et cela provoque également le fichier de configuration spécifié à
être enregistré dans l'image WIM en tant que Windows/System32/WimBootCompress.ini, remplaçant tout
qui peuvent être présents sur le système de fichiers.

--unix-données
(Systèmes de type UNIX uniquement) Stockez le propriétaire, le groupe, le mode et l'ID de périphérique UNIX (principal et
nombre mineur) de chaque fichier capturé. Depuis wimlib v1.7.0, vous pouvez sauvegarder et
restaurer non seulement les informations d'autorisation de fichier UNIX standard, mais aussi le caractère
les nœuds de périphérique, les nœuds de périphérique de bloc, les canaux nommés (FIFO) et les sockets de domaine UNIX.

wimlib stocke les données UNIX en ajoutant un élément de métadonnées balisé spécial à chaque répertoire
entrée de chaque fichier contenant ces informations. Cette information supplémentaire est
ignoré par l'implémentation de Microsoft. Remarque : les données UNIX stockées par wimlib avant
La v1.7.0 utilisait un format différent qui n'est plus pris en charge. Si vous avez un ancien WIM
fichiers avec des données UNIX, appliquez-les avec v1.6.2 et recapturez-les avec v1.7.0 ou
plus tard.

--pas d'acls
Ne capturez pas les descripteurs de sécurité des fichiers.

--strict-acls
Échoue immédiatement si le descripteur de sécurité complet d'un fichier ne peut pas être lu. Au
Windows, le comportement par défaut sans cette option est d'abord d'essayer d'omettre la SACL
du descripteur de sécurité, puis d'essayer d'omettre complètement le descripteur de sécurité.
Le but de ceci est de capturer autant de données que possible sans toujours avoir besoin de
Les privilèges d'administrateur. Cependant, si vous désirez que tous les descripteurs de sécurité soient
capturé exactement, vous souhaiterez peut-être fournir cette option, bien que l'administrateur
devrait avoir la permission de tout lire de toute façon.

--rpfix, --norpfix
Définir s'il faut corriger les cibles des liens symboliques absolus (points d'analyse dans Windows
terminologie) ou non. Lorsqu'il est activé (--rpfix), des liens symboliques absolus qui pointent
à l'intérieur de l'arborescence de répertoires en cours de capture sera ajustée pour être absolue par rapport à
la racine de l'arborescence de répertoires en cours de capture. Lorsqu'il est désactivé (--norpfix), absolu
les liens symboliques seront capturés exactement tels quels.

Le comportement par défaut pour wimlib-imagex capturer équivaut à --rpfixL’
comportement par défaut pour wimlib-imagex ajouter sera --rpfix si corrections de points de réparation
ont déjà été effectués le FICHIER WIMF, Autrement --norpfix.

Dans le cas d'une capture multi-source, (--Liste des sources spécifié), en passant --norpfix
est recommandé. Sinon, les corrections de points d'analyse seront désactivées sur toutes les captures
sources destinées à des emplacements non racine dans l'image WIM, tandis que les sources de capture
destiné à la racine WIM obtiendra le comportement par défaut du paragraphe précédent.

--Liste des sources
wimlib-imagex capturer ainsi que wimlib-imagex ajouter prise en charge de la création d'une image WIM à partir de
plusieurs fichiers ou répertoires séparés. Lorsque --Liste des sources est spécifié, le SOURCE
argument spécifie le nom d'un fichier texte, dont chaque ligne vaut 1 ou 2
chemins de fichiers séparés par des espaces. Le premier chemin de fichier, la source, spécifie le
chemin vers un fichier ou un répertoire à capturer dans l'image WIM. Il peut s'agir soit
absolu ou relatif au répertoire de travail courant. Le deuxième chemin de fichier, si
fourni, est la cible et spécifie le chemin dans l'image WIM que ce fichier ou
répertoire sera enregistré sous. Les barres obliques de début et de fin dans la cible sont ignorées,
sauf s'il est entièrement composé de barres obliques (par exemple "/"), ce qui indique que le
est de devenir la racine de l'image WIM. En cas d'omission, la chaîne cible
par défaut la même que la chaîne source.

Un exemple de fichier de liste de sources est le suivant :

# Créer l'image WIM à partir du répertoire 'winpe'
Winpe /

# Envoyez le répertoire 'overlay' à '/overlay' dans l'image WIM
superposition / superposition

# Superposez un répertoire séparé directement à la racine de l'image WIM.
/données/trucs /

Les sous-répertoires du WIM sont créés selon les besoins. Plusieurs répertoires sources peuvent
partagent la même cible, ce qui implique une superposition. Au cas où cela entraînerait une
fichier non-répertoire étant ajouté à l'image WIM plusieurs fois, la dernière version (comme
répertorié dans le fichier de liste des sources) remplace toute version antérieure.

Les chemins de fichiers contenant des espaces peuvent être entre guillemets simples ou doubles
devis. Les guillemets ne peuvent pas être échappés.

Lignes composées uniquement d'espaces et de lignes commençant par '#' précédées de
les espaces blancs facultatifs sont ignorés.

Comme cas particulier, si SOURCE est "-", la liste des sources est lue à partir de l'entrée standard
plutôt qu'un fichier externe.

Le mode de capture de volume NTFS sur les systèmes de type UNIX ne peut pas être utilisé avec --Liste des sources,
car seule la capture d'un volume NTFS complet est prise en charge.

--pipable
Créer un WIM « pipable », qui peut être appliqué de manière entièrement séquentielle, y compris à partir d'un
tuyau. Une image dans le WIM résultant peut être appliquée avec wimlib-imagex vous inscrire, Soit
normalement en spécifiant le nom du fichier WIM, ou avec wimlib-imagex vous inscrire - lire la
WIM à partir de l'entrée standard. Voir wimlib-imagex vous inscrire(1) pour plus de détails.

Pour les opérations d'ajout, cette option entraînera une reconstruction complète du WIM pour faire
c'est pipable. Pour les opérations de capture, le WIM capturé est simplement créé en tant que pipable.
Attention, plus vous ajoutez d'images à un WIM pipable, moins il est efficace
le sera, car davantage de données inutiles seront envoyées par le canal.

Lorsque wimlib crée un WIM pipable, il réorganise soigneusement les composants du
WIM afin qu'ils puissent être lus séquentiellement et fasse également plusieurs autres
modifications. Par conséquent, ces WIM « pipables » sont ne sauraient compatible avec
Microsoft ,software, alors gardez cela à l'esprit si vous comptez les utiliser. Si on le désire,
vous pouvez utiliser wimlib-imagex optimiser --non-pipable pour réécrire un WIM pipable en tant que
WIM régulier. (wimlib-imagex Exporter offre également la possibilité d'exporter des images
d'un WIM pipable à un WIM non pipable, ou vice versa.)

Pour la plupart, wimlib fonctionne de manière transparente sur des WIM pipables. Vous pouvez modifier
les, ajoutez ou supprimez des images, exportez des images et même créez des WIM fractionnés pouvant être pipés. Les
les principaux inconvénients sont que l'ajout est (actuellement) moins efficace (--reconstruire is
toujours implicite), et ils ne sont pas non plus compatibles avec les logiciels de Microsoft.

wimlib-imagex capturer ainsi que wimlib-imagex ajouter peut à la fois écrire un WIM pipable directement
à la sortie standard ; cela se fait automatiquement si FICHIER WIMF est spécifié comme "-". (Dans
ce cas, --pipable est assumé.)

--non-pipable
Assurez-vous que le WIM résultant est au format WIM normal et non-pipable. C'est le
par défaut pour wimlib-imagex capturer, sauf lors de l'écriture sur la sortie standard (FICHIER WIMF
spécifié comme "-"), et aussi pour wimlib-imagex ajouter, sauf lors de l'ajout à un WIM
c'est déjà pipable.

--mise à jour-de=[FICHIER WIMF:]IMAGE
Déclare que l'image capturée ou ajoutée à partir de SOURCE est en grande partie le même que
l'image existante IMAGE in FICHIER WIMF, mais capturé à un moment ultérieur, peut-être
avec quelques modifications dans l'intervalle. Ceci est conçu pour être utilisé dans
sauvegardes incrémentielles du même système de fichiers ou arborescence de répertoires. IMAGE peut être un
Index basé sur 1 ou nom d'une image existante dans FICHIER WIMF. Cela peut aussi être négatif
entier pour indexer en arrière dans les images (par exemple -1 signifie la dernière image existante
in FICHIER WIMF).

Lorsque cette option est fournie, la capture ou l'ajout de la nouvelle image sera
optimisé en ne lisant pas les fichiers qui, sur la base de métadonnées telles que les horodatages, apparaissent
ne pas avoir été modifiés depuis qu'ils ont été archivés dans l'existant IMAGE. Sauf
manipulation des horodatages, cette option n'affecte que les performances et ne change pas
l'image WIM résultante.

Comme indiqué, la syntaxe complète de l'argument de cette option consiste à spécifier le WIM
fichier, deux points et l'image ; par exemple, "--update-of mywim.wim:1". Cependant, le
Le fichier WIM et les deux points peuvent être omis, auquel cas le fichier WIM sera par défaut le
Fichier WIM en cours d'ajout pour les opérations d'ajout, ou le fichier WIM à partir duquel un delta
est prise (uniquement si --delta-de est spécifié exactement une fois) pour la capture
opérations.

--delta-de=FICHIER WIMF
Pour wimlib-imagex capturer uniquement : capturez le nouveau WIM en tant que « delta » à partir de FICHIER WIMF. Tout
les flux qui devraient normalement être archivés dans le nouveau WIM sont omis s'ils
sont déjà présents dans le FICHIER WIMF sur laquelle le delta est basé. Le nouveau WIM
contiendra toujours une copie complète des métadonnées de l'image, mais ce n'est généralement qu'un
petite fraction de la taille totale d'un WIM.

Cette option peut être spécifiée plusieurs fois, auquel cas le delta WIM résultant
contiendra uniquement des flux qui ne sont présents dans aucun des WIM de base spécifiés.

Pour opérer sur le delta WIM résultant en utilisant d'autres commandes telles que wimlib-imagex
vous inscrire, vous devez spécifier le delta WIM comme fichier WIM sur lequel opérer, mais aussi
référencer le(s) WIM de base à l'aide du --réf option. Attention : pour conserver le bon
fonctionnement du delta WIM, vous pouvez uniquement ajouter, et non supprimer, des fichiers et des images au
WIM de base suite à la capture d'un delta à partir de celui-ci.

--delta-de peut être combiné avec --mise à jour-de augmenter la vitesse de capture d'un
deltaWIM.

À titre d'exemple, considérons la séquence de sauvegarde et de restauration suivante :

(sauvegarde initiale)

$ wimcapture /certain/répertoire bkup-base.wim

(quelques jours plus tard, créez une deuxième sauvegarde en tant que delta à partir de la première)

$ wimcapture /certain/répertoire bkup-2013-08-20.dwm \
--update-of bkup-base.wim:-1 --delta-from bkup-base.wim

(restauration de la deuxième sauvegarde)

$ wimapply bkup-2013-08-20.dwm --ref=bkup-base.wim 1 \
/quelques/répertoire

Cependant, notez que comme alternative à la séquence ci-dessus qui utilisait un delta WIM,
la deuxième sauvegarde aurait pu être simplement ajoutée au WIM en tant que nouvelle image en utilisant
wimlib-imagex ajouter. Les WIM Delta ne doivent être utilisés que si l'on souhaite baser le
sauvegardes ou images sur un fichier séparé et volumineux qui est rarement modifié.

Remarque : contrairement aux WIM « pipables » (créés avec le --pipable option), les WIM "delta"
(créé avec le --delta-de option) sont compatibles avec les logiciels de Microsoft.
Par exemple, vous pouvez utiliser l'option /ref d'ImageX pour référencer le(s) WIM de base,
similaire à ci-dessus.

Remarque additionnelle: wimlib-imagex est suffisamment généralisé pour que vous puissiez en fait combiner
--pipable ainsi que --delta-de pour créer des WIM delta exploitables. Dans de tels cas, la base
Les WIM doivent être capturés en tant que pipable ainsi que le delta WIM, et lors de l'application d'un
image, le ou les WIM de base doivent être envoyés sur le canal après le WIM delta.

--wimboot
Marquez l'image comme compatible WIMBoot. Voir la documentation de Microsoft pour plus
informations sur WIMBoot. Cette option définira par défaut le type de compression
à XPRESS et la taille de bloc à 4096 octets ; ceux-ci peuvent, cependant, toujours être annulés
par l'intermédiaire du --compresse ainsi que --chunk-taille paramètres, respectivement. De plus, ce
L'option définira, par défaut, le fichier de configuration sur
SOURCE\Windows\System32\WimBootCompress.ini si présent et accessible ; cependant, ce
peut encore être outrepassé par le --config paramètre.

--unsafe-compact
Voir la documentation de cette option dans wimlib-imagex-optimiser (1).

--instantané
EXPÉRIMENTAL : créez un instantané du système de fichiers temporaire du répertoire source et
capturer les fichiers à partir de celui-ci. Actuellement, cette option n'est prise en charge que sous Windows,
où il utilise le service de cliché instantané de volume (VSS). En utilisant cette option, vous pouvez
créer une sauvegarde cohérente du volume système d'un système Windows en cours d'exécution sans
rencontrer des problèmes avec les fichiers verrouillés. Pour que l'instantané VSS soit réussi
créé, wimlib-imagex doit être exécuté en tant qu'administrateur et ne peut pas être exécuté dans
Mode WoW64 (c'est-à-dire si Windows est en 64 bits, alors wimlib-imagex doit également être en 64 bits).

NOTES


wimlib-imagex ajouter ne prend pas en charge l'ajout d'une image à un WIM divisé.

Sauf lors de l'utilisation --unsafe-compact, vous pouvez annuler un wimlib-imagex ajouter commander
à mi-chemin ; cependant, après avoir fait cela, il est recommandé d'exécuter wimlib-imagex
optimiser pour supprimer toutes les données qui ont été ajoutées au fichier WIM physique mais pas encore
incorporé dans la structure du WIM, à moins que le WIM ne soit entièrement reconstruit (par ex.
avec --reconstruire), auquel cas vous devez supprimer le fichier temporaire restant.

wimlib-imagex crée des WIM compatibles avec les logiciels de Microsoft (WIMGAPI, ImageX, DISM),
avec quelques mises en garde :

· Avec wimlib-imagex sur les systèmes de type UNIX, il est possible de créer une image WIM
contenant des fichiers dont les noms ne diffèrent que par la casse, ou des fichiers dont les noms contiennent le
caractères ':', '*', '?', '"', '<', '>', '|' ou '\', qui sont valides sur POSIX-
systèmes de fichiers compatibles mais pas Windows. Soyez averti que ces fichiers ne seront pas
extrait par défaut par la version Windows de wimlib-imagex, et (encore pire)
ImageX de Microsoft peut être confondu par de tels noms et arrêter d'extraire l'image à mi-chemin
par. (Il vaut peut-être la peine de souligner que le système de fichiers par défaut de Windows,
NTFS, prend en charge ces caractères, contrairement à Windows !)

· Les WIMs pipables sont incompatibles avec les logiciels de Microsoft. Les WIM pipables sont créés
seulement si FICHIER WIMF a été spécifié comme "-" (sortie standard) ou si le --pipable le drapeau était
spécifié.

· WIM capturés avec une taille de bloc autre que celle par défaut (avec le --chunk-taille option) ou comme solide
archives (avec le --solide option) ou avec compression LZMS (avec --compresse=LZMS ou
--compresse=recovery) ont des niveaux de compatibilité variables avec les logiciels de Microsoft.
Généralement, les versions plus récentes des logiciels de Microsoft sont plus compatibles.

EXEMPLES


Premier exemple : créez un nouveau WIM 'mywim.wim' avec une compression LZX ("maximum") qui
contiennent une image capturée de l'arborescence de répertoires 'somedir'. Notez que le nom de l'image doit
pas être spécifié et sera par défaut 'somedir' :

wimlib-imagex capture un répertoire mywim.wim

ou, si le wimcapture lien physique ou fichier batch a été installé, le formulaire abrégé peut
être utilisé:

wimcapture un répertoire monwim.wim

Les autres exemples utiliseront cependant la forme longue. Ensuite, ajoutez l'image d'un
arborescence de répertoires différente du WIM créé ci-dessus :

wimlib-imagex ajoute un autre répertoire mywim.wim

Assez facile, et les exemples ci-dessus d'arborescences de répertoires d'imagerie fonctionnent à la fois sur UNIX
systèmes et Windows. Ensuite, capturez un WIM avec plusieurs options non par défaut, y compris
Compression XPRESS ("rapide"), une table d'intégrité, pas de pagaille avec des liens symboliques absolus,
et un nom d'image et une description :

wimlib-imagex capture un répertoire mywim.wim --compress=fast \
--check --norpfix "Un nom" "Une description"

Capturez un volume NTFS entier dans un nouveau fichier WIM et nommez l'image "Windows 7". Au
systèmes de type UNIX, cela nécessite d'utiliser le mode spécial décrit dans NTFS LE VOLUME CAPTURER
(UNIX) De SOURCE est un fichier ou un périphérique bloc contenant un système de fichiers NTFS :

wimlib-imagex capture /dev/sda2 windows7.wim "Windows 7"

ou, sous Windows, pour capturer un volume NTFS complet, vous devez à la place spécifier la racine
répertoire du volume monté, par exemple :

wimlib-imagex capture E:\ windows7.wim "Windows 7"

Identique à l'exemple ci-dessus avec la capture d'un volume NTFS à partir de wimlib-imagex fonctionnant sous UNIX-
comme le système, mais capturez le WIM dans le format "pipable" spécifique à wimlib qui peut être redirigé
à wimlib-imagex vous inscrire:

wimlib-imagex capture /dev/sda2 windows7.wim "Windows 7" \
--pipable

Identique à ci-dessus, mais au lieu d'écrire le WIM pipable dans le fichier "windows7.wim", écrivez-le
directement à la sortie standard via un tuyau dans un autre programme "someprog", qui
pourrait, par exemple, être un programme ou un script qui diffuse les données vers un serveur. Noter que
--pipable n'a pas besoin d'être explicitement spécifié lors de l'utilisation de la sortie standard comme "fichier" WIM :

wimlib-imagex capture /dev/sda2 - "Windows 7" | un prog

Utiliser wimcapture en ligne en utilisant les services onworks.net


Serveurs et postes de travail gratuits

Télécharger des applications Windows et Linux

  • 1
    Zabbix
    Zabbix
    Zabbix est un logiciel ouvert de classe entreprise
    source solution de surveillance distribuée
    conçu pour surveiller et suivre
    performances et disponibilité du réseau
    serveurs, appareil...
    Télécharger Zabbix
  • 2
    KDiff3Name
    KDiff3Name
    Ce référentiel n'est plus maintenu
    et est conservé à des fins d'archivage. Voir
    https://invent.kde.org/sdk/kdiff3 for
    le code le plus récent et
    https://download.kde.o...
    Télécharger KDiff3
  • 3
    Chargeur USBGX
    Chargeur USBGX
    USBLoaderGX est une interface graphique pour
    Le chargeur USB de Waninkoko, basé sur
    libwigui. Il permet de répertorier et
    lancer des jeux Wii, des jeux Gamecube et
    homebrew sur Wii et WiiU...
    Télécharger USBLoaderGX
  • 4
    Firebird
    Firebird
    Firebird RDBMS offre des fonctionnalités ANSI SQL
    & fonctionne sous Linux, Windows &
    plusieurs plates-formes Unix. Fonctionnalités
    excellente simultanéité et performances
    & Puissance...
    Télécharger Firebird
  • 5
    KompoZer
    KompoZer
    KompoZer est un éditeur HTML wysiwyg utilisant
    la base de code de Mozilla Composer. Comme
    Le développement de Nvu a été arrêté
    en 2005, KompoZer corrige de nombreux bugs et
    ajoute un f...
    Télécharger KompoZer
  • 6
    Téléchargeur de mangas gratuit
    Téléchargeur de mangas gratuit
    Le Free Manga Downloader (FMD) est un
    application open source écrite en
    Object-Pascal pour la gestion et
    télécharger des mangas à partir de divers sites Web.
    C'est un miroir...
    Télécharger gratuitement Manga Downloader
  • Plus "

Commandes Linux

Ad