Sur un volume NTFS Win7, j'utilise cwrsync qui prend correctement en charge --link-dest pour créer des sauvegardes de type "instantané". Donc j'ai:
z:\backups\2010-11-28\cygdrive\c\Users\...
z:\backups\2010-12-02\cygdrive\c\Users\...
Le contenu du 02/12/2010 est principalement constitué de liens physiques vers des fichiers du répertoire du 28/11/2010, mais il n'y a quelques fichiers nouveaux ou modifiés qu'en 2010-12-02. Sous Linux, l'utilitaire «du» me dira la taille réelle prise par chaque instantané incrémentiel. Sous Windows, explorer et du sous cygwin sont tous deux dupés par les liens physiques et montrent que le 2010-12-02 occupe un peu plus d'espace que le 2010-11-28.
Existe-t-il un utilitaire Windows qui montrera l'espace correct utilisé de manière effective?
Réponses:
Essayez d'utiliser Sysinternals Disk Usage (autrement connu sous le nom de
du
), en utilisant spécifiquement les indicateurs-u
et-v
ne comptera que les occurrences uniques et affichera l'utilisation de chaque dossier au fur et à mesure.Pour autant que je sache, le système de fichiers ne montre pas la différence entre le fichier d'origine et un lien dur (c'est vraiment le but d'un lien dur), vous ne pouvez donc pas les actualiser dossier par dossier, mais besoin de le faire comparativement.
Pour tester, j'ai créé un dossier aléatoire avec 6 fichiers dans. Cloné le tout. Ensuite, créé plusieurs liens matériels et logiciels à l'intérieur du premier dossier pour référencer d'autres fichiers dans le premier dossier, ainsi que certains dans le second.
L'exécution des
du -u -v testFld
résultats dans (notez que les valeurs à côté des dossiers sont en Ko):du -u -v testFld\a
Résultats en cours d'exécution dans:du -u -v testFld\b
Résultats en cours d'exécution dans:Remarquez le décalage?
Les liens symboliques dans A qui font référence à des fichiers dans B ne sont pris en compte dans A que lors de l'exécution «complète», et B ne renvoie que 54 (même si les fichiers étaient à l'origine dans B et liés à partir de A). Lorsque vous mesurez B séparément (ou, si vous n'utilisez pas l'
-u
indicateur unique), il comptera sa mesure "complète" de 74.la source
-u
drapeau. Vous obtenez la mesure "complète" si vous utilisez le-u
drapeau. Sans lui, il ne compte qu'une seule instance de tout fichier lié en dur. Dit ainsi dans les documents: docs.microsoft.com/en-gb/sysinternals/downloads/du et les tests le vérifient.PowerShell 5 peut être une option. Il est disponible pour Windows 7 mais je l'ai testé uniquement sur un serveur 2012 R2 avec la prévisualisation d'avril 2015
Le fournisseur de système de fichiers dans PowerShell 5 a deux nouvelles propriétés
LinkType
etTarget
:cela renvoie:
Alors maintenant, je ne peux afficher que tous les fichiers dans system32 qui ne sont pas des liens physiques:
cela renvoie:
vous pouvez comparer cela avec tous les fichiers:
Donc, plus de 13 000 fichiers avec 2 Go + sont des liens physiques
la source
TreeSize Professional (~ 55 $, essai de 30 jours) prétend distinguer l'espace disque dur NTFS. Un essai rapide semble le confirmer.
La prise en charge du lien matériel n'est pas activée dès le départ: accédez à Outils> Options> Numériser , numérisez à nouveau, puis utilisez
Ctrl-1
etCtrl-2
pour basculer entre Taille et Espace alloué . L'allocation est l'espace réel utilisé, tandis que la taille est la statistique normalement rapportée par d'autres programmes.Il y a une pénalité de performance pour activer la prise en charge des liens physiques (et les liens symboliques et les montages aussi si vous le souhaitez également). La palette de couleurs est criarde à mon goût, mais cela semble être comparable au cours dans ce genre. Soyez également prudent lorsque vous cliquez dans la zone de graphique en boîte - il est facile de déplacer accidentellement un dossier avec un glisser-déposer erroné lorsque vous vouliez uniquement le développer.
la source
Je pense que certains faits doivent être définis ici.
Windows ne peut pas "détecter" les liens physiques, car chaque fichier est en fait un lien physique vers un tas d'octets sur le disque.
L'outil du détecte les doublons, mais c'est faux aussi, car si le dossier A contient des fichiers et B ne contient que des liens durs vers les fichiers dans A, alors du de A et du du B renverra la même réponse - la taille des fichiers provenant à l'origine de A, mais ces fichiers sont maintenant également en B.
C'est en fait correct, car par exemple, si vous avez supprimé A, ses fichiers ne seront pas supprimés sur le disque, car ils sont toujours référencés par B. Avec des liens physiques, quel fichier est la source et lequel est le lien physique est tout à fait arbitraire et dénué de sens.
Des produits tels que du répertorieront un répertoire tout en actualisant les doublons. Cela ne fonctionnera que si tous les fichiers et liens physiques sont contenus dans un seul répertoire. De nombreux produits de liste de dossiers le font.
Conclusion: Avec les liens physiques, la question de "la taille réelle utilisée dans un répertoire NTFS" n'a pas de sens.
la source
Je fais également des recherches sur cette question. Voici les résultats que j'ai découverts.
La taille du dossier contenant des fichiers liés en dur dans NTFS peut être considérée dans trois sens différents:
Le nombre 2 correspond à ce qui est affiché par TreeSize Professional, dans l'onglet Détails, dans la colonne Allouée, si l'option "Suivre les liens physiques NTFS" est activée.
Voici un exemple pour le dossier Winsxs (7,5 Go en opposition à 10):
Recevoir la valeur numéro 3 est toujours une question pour moi. Bien que j'ai pu obtenir une limite inférieure en utilisant Total Commander avec le plugin NL_Info. Ce que j'ai, c'est une taille occupée par des fichiers qui ont un seul lien dur (fichiers uniques). Il était d'environ 5 Go pour un exemple donné.
Donc, essayez d'élargir la réponse de harrymc ou de dire en d'autres termes.
la source
Vous pouvez utiliser ln.exe pour afficher la "taille réelle" d'une arborescence de répertoires:
Il ne détectera que les liens physiques en dessous de ce dossier de départ.
la source