Comment puis-je vérifier la taille réelle utilisée dans un répertoire NTFS avec de nombreux liens physiques?

14

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?

windows-7 ntfs hardlink

— kbyrd
source

Des outils permettant de résoudre ce problème seraient très utiles pour obtenir une image précise de Pourquoi le dossier / winsxs devient-il si grand et peut-il être plus petit? et

— Matt Wilkie

cela semble être la question de dé-facteur et les réponses pour une utilisation normale du disque: Comment puis-je visualiser l'utilisation du système de fichiers sous Windows?

— Matt Wilkie

11

Essayez d'utiliser Sysinternals Disk Usage (autrement connu sous le nom de du), en utilisant spécifiquement les indicateurs -uet -vne 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 testFldrésultats dans (notez que les valeurs à côté des dossiers sont en Ko):

       104  <path>\testFld\A
        54  <path>\testFld\B
       149  <path>\testFld

Totals:
Files:        12
Directories:  2
Size:         162,794 bytes
Size on disk: 162,794 bytes

du -u -v testFld\aRésultats en cours d'exécution dans:

104  <path>\testFld\a
...

du -u -v testFld\bRésultats en cours d'exécution dans:

74   <path>\testFld\b
...

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' -uindicateur unique), il comptera sa mesure "complète" de 74.

— DMA57361
source

1

Merci, je ne connaissais pas les sysinternals du, juste le cygwin. Apparemment, le cygwin du fait ce que je veux aussi, je n'ai tout simplement pas pensé à l'essayer avant de commencer la prime.

— kbyrd

Cette réponse confond la fonction du -udrapeau. Vous obtenez la mesure "complète" si vous utilisez le -udrapeau. 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.

— martixy

2

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 LinkTypeet Target:

ls taskmgr.exe | fl LinkType,Target

cela renvoie:

LinkType : HardLink
Target   : C:\Windows\WinSxS\amd64_microsoft-windows-advancedtaskmanager_..._6.3.9600.17..2\Taskmgr.exe

Alors maintenant, je ne peux afficher que tous les fichiers dans system32 qui ne sont pas des liens physiques:

cd $env:SystemRoot\System32
ls -Recurse -File -force -ErrorAction SilentlyContinue | ? LinkType -ne HardLink | Measure-Object -Property Length -Sum

cela renvoie:

Count    : 844
Sum      : 502,486,831

vous pouvez comparer cela avec tous les fichiers:

ls -Recurse -File -force -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum

Count    : 14092
Sum      : 2,538,256,262

Donc, plus de 13 000 fichiers avec 2 Go + sont des liens physiques

— Peter Hahndorf
source

1

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-1et Ctrl-2pour 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.

— Matt Wilkie
source

1

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.

— harrymc
source

1

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:

Taille, y compris les tailles de tous les fichiers liés en dur (qui est montrée par WE).
Taille des fichiers uniques uniquement en fonction du dossier actuel.
Taille des fichiers uniques uniquement en termes de disque entier.

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.

— tschesseket
source

0

Vous pouvez utiliser ln.exe pour afficher la "taille réelle" d'une arborescence de répertoires:

ln.exe --truesize z:\backups\.

Il ne détectera que les liens physiques en dessous de ce dossier de départ.

— Limer
source