Discussion :

[hanuman]

Bonjour,

Je sèche un peu sur une API qui me semblait idiote de prime abord:

Je dois vider la corbeille de tous les utilisateurs. J'utilise cette fonction:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
 
[DllImport("shell32.dll")]
public static extern int SHEmptyRecycleBin( IntPtr hwnd, string
 pszRootPath, SHERB_FLAGS dwFlags);

L'inconvénient c'est qu'elle efface uniquement la corbeille de l'utilisateur connecté.
1) Je ne savais pas que la corbeille était liée à une session, après vérification, si je supprime un document sur une session, elle n'apparait pas dans la corbeille d'une autre session (même s'il s'agit d'un fichier d'un répertoire commun comme C:\, etc...).
2) J'ai déja activé l'option qui permet de voir le répertoire C:\RECYCLER et ses sous-répertoires. Les fichiers supprimés ds autres session n'apparaissent pas dedans non plus.

J'ai cherché des heures sur le net, j'ai rien trouvé d'utile. Si quelqu'un avait un début de piste...

Merçi d'avance.

[cinemania]

Première piste, oui la corbeille est dépendante de la session.

Ensuite, pourquoi voudrait tu vider la corbeille d'autres sessions ?
Ensuite, la raison pour laquelle ca ne "fonctionne" pas c'est pour une question évidente de sécurité. En effet, sur un compte limité comme un compte invité, ou utilisateur simple, (sur XP par exemple) il ne semble pas approprié qu'une application puisse vider la corbeille de l'administrateur, n'est ce pas ?

Enfin je sais pas, mais moi ca me semble logique. Donc comme l'application à priori n'a pas à savoir si elle est "administratrice" ou pas. Les règles de sécurités veulent que l'isolation se fasse.
Voila une des raisons qui font que les corbeilles sont dépendantes de la sessions et qu'on ne peut pas vider les corbeilles des autres sessions.

Autre piste. quand tu te connecte en administrateur, ta déjà essayé de vider les corbeilles des autres sans accèder à leur session ?
tu peux pas, en effet, tu ne vois que le contenu de ta propre corbeille, ce qui me semble assez logique.

Bref, je vois pas de quel droit tu voudrais vider la corbeille des autres utilisateurs, seule la tienne suffit, puisque de toute facon tu ne peux rien ajouté ou retiré à la corbeille des autres, tu peux meme pas la consulter.

Quand tu regarde le contenu du répertoire Recycled, oublie pas que l'explorer utilise le shell pour ca.. et comme par hasard, le shell ne lui retourne que les entités de la corbeille de la session en cours, pas celle des autres... voila pourquoi tu ne vois pas qu'il y a plusieurs corbeilles.

[hanuman]

Je dois vider la corbeille des autres utilisateurs pour une raison très simple: Ils ne le font pas...et il s'agit d'une station de travail avec beaucoup d'utilisateurs et un espace disque limité.
Le thread a les droits d'administrateurs bien entendu.
Et si un administrateur a le droit de visionner les documents des autres profils (ou même de changer le mot de passe des autres sessions [Raison évidente de sécurité...], pourquoi ne pourrait-il pas modifier le contenu de la corbeille?
Si un utilisateur supprimer un fichier sur une partition commune aux sessions, les autres utilisateurs ne peuvent pas le voir? Ca ne me semble pas très logique non plus.
Le shell renvoie bien un répertoire virtuel pour RECYCLER (répertoire qui ne contient pas les fichiers supprimés mais un fichier INFO contenant des métadonnées sur les fichier supprimés).
Personnellement j'ai du mal à croire que crosoft n'ai pas prévu quelque chose pour pallier aux utilisateurs ne vidant jamais leur corbeille.

[toniolol]

j'ai du mal à croire que crosoft n'ai pas prévu quelque chose pour pallier aux utilisateurs ne vidant jamais leur corbeille.

Un truc con mais tu peux régler la taille (en %) de la poubelle ou la désactiver, ce qui est supprimé est supprimé !

[hanuman]

Oui, je sais malheureusement (et pour une raison farfelue), je ne peux pas empêcher l'utilisateur de gérer sa corbeille mais je peux la lui vider

[abelman]

Salut,

Tu peux toujours faire en sorte que ton code s'execute sous la session de l'utilisateur en question. Cela suppose que tu as la liste des utilisateurs en questions (login + mdpasse) ....

- Soit tu le fais directement dans ton code: Ouvrir une session user avant de vider la corbeille. Il faut connaitre les API ou classes pour le faire (je ne maitrise pas).

- Soit tu ne changes pas ton code mais tu crée une ptite appli qui lance ton code via l'utilitaire RunAs

Bon courage

[hanuman]

Je ne peux pas utiliser l'impersonalisation, je n'ai pas la liste des mot de passe (autant via Active directory que windows, il n'y a pas moyen de récupérer la liste des mot de passe excepté par une saisie au clavier de l'uilisateur. Pour info, la dll c'est shell32.dll et la fonction LogonUser).
L'utilisateur n'est pas censé devoir le faire lui-même et le programme doit pouvoir le faire même pour les sessions qui ne sont pas ouverte (pas de batch en background au démarrage de session alors).
(Entre nous, je ne comprend pas non plus trop l'interêt mais bon....faut suivre les demandes du chef de projet).

[cinemania]

en réalité le fichier de métainfo est stoqué dans les données de chaque session. Si tu connais tous les login et le nom du fichier incriminé, tu peux lire ce fichier dans chaque session de facon incrémentale et le "purger" manuellement.

Seulement ca, c'est de la théorie. car en pratique, et bien les problème s'amonceles. En effet, cela ne peut fonctionner que sur des sessions qui ne sont pas ouvertes, si une session est ouverte, ce fichier etant en cours d'utilisation par le systeme, tu ne peux pas y accèder, surtout pas en écriture, le systeme se reserve ce droit de facon légitime. Ensuite, faut trouver le bon fichier, et là, perso je sais pas du tout ou ils l'ont planqués, peut etre est t'il dans la base de registre, mais ca j'en doute sérieusement car je ne me souviens pas avoir vu quelque chose de tel lors de mes fouilles. Et il se peut également que ces métadonnées soient stoquées dans un fichier qui contient d'autres informations, comme un des fichiers dans la racine de chaque session.
Pour l'instant à part cette solution, visiblement pas gagnée d'avance je vois mal comment contourner la sécurité.

En ce qui concerne le RunAs, si mes souvenirs sont bons, une application/service avec privilèges administrateurs n'a pas besoin du mot de passe de session pour y accèder, après tout, c'est totalement inutile. C'est comme un su user sous linux, il est inutile de spécifier le password si tu est administrateur, si mes souvenirs sont bons, c'est un peu le meme principe là toutefois je peux me tromper ca fait tellement longtemps que j'ai pas joué avec ses fonctionnalités

Il y a d'ailleurs à ce sujet une piste à explorer. Malheureusement je doute que celle-ci soit réalisable en managé. L'idée consiste à créer non pas une application mais un service d'arrière plan, qui est installé et tourne TOUJOURS, hors session, un service non rataché a une session, ainsi ce service fonctionne avec les privilège SYSTEME nettements supérieurs aux privilèges administrateurs et dans ce cas, je pense qu'il est possible toujours par l'api Shell de faire quelque chose, mais là encore, ce n'est qu'une idée et une hypothèse, si quelqu'un a deja essayé... qu'il se fasse connaitre, ca serait sympa.