Le répertoire non caché ne montre pas dans l'explorateur, mais le programme qui l'a fait peut y accéder.
J'utilise Imapapsize pour sauvegarder mes boîtes aux lettres. Le processus vise simplement le contenu de votre boîte aux lettres dans .eml Fichiers sur votre disque. Quoi qu'il en soit, la première boîte aux lettres que j'ai sauvegardée apparaît comme je m'attends. Cependant, le prochain ne montre pas dans Explorer et, si je l'entre dans la barre d'adresse, il me dit que cela n'existe pas.
Cependant, l'imapapisation insiste pour que les fichiers soient là. (Beaucoup d'écriture de disque ont été effectués pendant l'opération.) De plus, le répertoire apparaît dans la boîte de dialogue Répertoire Windows et - comme j'ai GNU outils installés - il affiche en ls (mais pas dans le natif dir). Je ne peux pas cd dans le répertoire, mais ls semble pouvoir y accéder (et, en effet, les répertoires et les fichiers que j'attends semblent être là).
Notez également que l'horodatage et la définition de backup.db sont différents dans le dir et ls -l sortir.
En bref: qu'est-ce qui se passe ici et comment puis-je le réparer !?
Permettez-moi de deviner: le programme qui a créé le fichier, ainsi que les GNU Utilities ne s'exécute pas en tant qu'administrateur.
Premièrement, une certaine histoire. Aux jours de Windows XP, de nombreux programmes supposés qu'ils seraient toujours exécutés comme administrateur et écriraient à des endroits comme C:\Windows Et C:\Program Files (x86) avec abandon sauvage. Avec Vista, Microsoft a essayé de faire moins d'administrateurs de personnes, mais les utilisateurs standard ne peuvent pas écrire à ces endroits. Ils avaient besoin de ces programmes douteux pour continuer à travailler (sinon les gens ne mettraient pas la mise à niveau). Donc, ils ont introduit une caractéristique magique appelée Virtualisation de l'UAC.
Les programmes fonctionnant comme des utilisateurs standard pourraient penser que leurs écritures sur des emplacements importants ont réussi, mais en réalité, Windows s'est écaillé les données dans un emplacement par utilisateur. Lorsque ces programmes recherchent des fichiers dans un répertoire, Windows vérifie pour voir s'il existe des fichiers dans le magasin virtuel de cet endroit, et le cas échéant, il les ajoute à la liste des répertoires. (Il y a une fonctionnalité équivalente pour le registre.)
Cela ressemble à votre programme de messagerie essayé d'écrire à un endroit sous Program Files (x86) lors de l'exécution d'un utilisateur normal. L'écriture a été redirigée, de sorte que cela ne s'est pas réellement allé à cet endroit. Le programme peut toujours le voir, car Windows la maintient l'illusion pour cela. L'explorateur ne le voit pas parce qu'il annonce au système d'exploitation qu'il se comporte bien et n'a pas besoin de redirection. La commande de la demande de commande dir n'est pas un programme (il s'agit simplement d'une fonctionnalité de cmd.exe). Il est donc également considéré comme "dans le savoir" et n'a donc pas montré les fichiers de compatibilité. ls est un programme qui est évidemment pas dans le savoir, il faut donc voir les fichiers de compatibilité.
Vous trouverez votre fichier ici:
%LOCALAPPDATA%\VirtualStore\Program Files (x86)\IMAPSize\backup
Tout en piquant dans VirtualStore, vous serez peut-être surpris de ce que les programmes ne sont pas bien élevés et ont besoin du filet de sécurité de la virtualisation.
Si vous souhaitez arrêter la redirection, exécutez le programme en tant qu'administrateur ou enregistrez vos sauvegardes dans un emplacement que vous pouvez réellement écrire sur sans privilèges d'administration.