Propriétés de la corbeille

Version imprimable

22/01/2022, 09h30
castorcharly

Propriétés de la corbeille

Bonjour,

Je cherche à lire les paramètres de la corbeille, c'est à dire les espaces réservés par partition ou média complet.
J'ai bien trouvé et exploité les deux API SHQueryRecycleBin et SHEmptyRecycleBin, mais pas moyen de trouver dans
les ressources ce qui me permettrais de trouver le moyen de lire ces propriétés.

Si vous avez une idée, je suis preneur,

merci
23/01/2022, 11h53
Jipété

Bonjour,

-- je n'ai rien testé, me suis contenté de lire (et pour cause ! Je suis sous Linux, :P) --

une première lecture intéressante, mais peut-être un peu vieillotte :
https://gist.github.com/maul-esel/1808118

une deuxième, en purebasic donc ça doit pouvoir s'adapter facilement
https://www.purebasic.fr/french/viewtopic.php?p=210871

et peut-être que ça pourrait être la solution à ce problème vieux de 12 ans posté dans un sous-forum de dvlp :
https://www.developpez.net/forums/d8...in-seven-64-a/

Bon code et bon dimanche,
28/01/2022, 10h03
castorcharly

Bonjour Jipété,

Merci pour ta recherche, mais malheureusement ce que tu as trouvé ne concerne que les deux API que j'ai trouvé sur la corbeille,
l'interrogation du nombre de fichier et le volume de ces fichiers via SHQueryRecycleBin et
le vidage de la corbeille via ShEmptyRecyclebin.

Moi, ce que je cherche, ce sont les propriétés de la corbeille:
- La liste des disques pourvu d'une corbeille et la place allouée, pour chaque disque, à chaque corbeille.

Mon objectif étant de savoir, si la place allouée est suffisante pour recevoir un fichier de volume conséquent.
Car si ce n'est pas le cas, lors de l'envoi de fichier vers la corbeille, si on affiche le dialog de suppression de fichier,
le système propose de supprimer le fichier définitivement sans possibilité de UNDO, soit d'annuler l'opération.
Et ces deux solutions ne me conviennent pas.
Je veux savoir avant le lancement en corbeille, si l'espace alloué est suffisant pour contenir les fichiers envoyés dans cette corbeille.

Merci

Bonjour,

je serai parti sur des WMI mais même avec Wmi Delphi Code Creator je ne vois pas vraiment ce que je cherche :calim2:
ou alors par les registres pour obtenir le nom :koi:

Sinon avec IOUtils et le nom il est relativement facile d'obtenir la taille
code FMX
Code:

1 2 3 if TDirectory.Exists('C:\$RECYCLE.BIN') then label1.Text:= TFile.GetSize('C:\$RECYCLE.BIN').ToString else label1.Text:='non accessible';
j'ai essayé ça pour obtenir le path
Code:

1 2 3 4 5 6 7 8 9 10 function GetMyPoubelle : string; var r: Bool; path: array[0..Max_Path] of Char; begin r := ShGetSpecialFolderPath(0, path, CSIDL_BITBUCKET, False) ; if not r then raise Exception.Create('Could not find recyclebin folder location.') ; Result := Path; end;
mais sans résultat : exception levée

Mon D10 n'a pas encore GetSize et la méthode par FindFirst renvoie 0 pour ces dossiers

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\BitBucket\Volumeon trouve la taille maximale mais j'ignore comment associé le GUID à au disque

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
procedure TForm.ButtonClick(Sender: TObject);
 
  function GetFileSize(const APath: string): Int64;
  var
    Sr : TSearchRec;
  Begin
    if FindFirst(APath, faAnyFile, Sr) =  0 then
    begin
      try
        LARGE_INTEGER(Result).HighPart := Sr.FindData.nFileSizeHigh; // 0 !
        LARGE_INTEGER(Result).LowPart := Sr.FindData.nFileSizeLow; // 0 !
      finally
        FindClose(Sr);
      end
    end
    else
      Result := 0;
  end;
 
var
  C: Char;
  Info: SHQUERYRBINFO;
begin
  for C := 'A' to 'Z' do
  begin
    ZeroMemory(@Info, SizeOf(Info));
    Info.cbSize := SizeOf(Info);
    if SHQueryRecycleBin(PWideChar(C + ':\'), @Info) = s_OK then
      Memo.Lines.Add(Format('%s:\ - Taille occupée : %do pour %d éléments sur taille maximale %d', [C, Info.i64Size, Info.i64NumItems, GetFileSize(Format('%s:\$RECYCLE.BIN', [C]))]));
  end;
end;

GUID trouvé !

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
procedure TForm.ButtonClick(Sender: TObject);
 
  function GetBucketSize(C: Char): Int64;
  var
    VolumeName: array[0..MAX_PATH] of Char;
  Begin
    Result := 0;
    // Bug de déclaration  GetVolumeNameForVolumeMountPointW en LPCSTR au lieu de LPCWSTR
    if GetVolumeNameForVolumeMountPoint(PAnsiChar(PByte(C + ':\')), @VolumeName[0], MAX_PATH) then
    begin
      with TRegistry.Create(KEY_READ) do
      try
        if OpenKey('Software\Microsoft\Windows\CurrentVersion\Explorer\BitBucket\Volume', False) then
        begin
          if OpenKey(StringReplace(StringReplace(VolumeName, '\\?\Volume', '', []), '\', '', []), False) then
          begin
            Result := ReadInteger('MaxCapacity');
            Result := Result * 1024 * 1024;
          end
          else
            Result := -2;
        end
        else
          Result := -1;
      finally
        Free();
      end;
    end
    else
      RaiseLastOSError();
  end;
 
var
  C: Char;
  Info: SHQUERYRBINFO;
begin
  for C := 'A' to 'Z' do
  begin
    ZeroMemory(@Info, SizeOf(Info));
    Info.cbSize := SizeOf(Info);
    if SHQueryRecycleBin(PWideChar(C + ':\'), @Info) = s_OK then
      Memo.Lines.Add(Format('%s:\ - Taille occupée : %do pour %d éléments sur taille maximale %do', [C, Info.i64Size, Info.i64NumItems, GetBucketSize(C)]));
  end;
end;

28/01/2022, 14h00
ShaiLeTroll
je confirme que ça donne les chiffres sur le clic droit de la corbeille sur deux PC différents

Citation:

C:\ - Taille occupée : 9086280o pour 19 éléments sur taille maximale 14898167808o
D:\ - Taille occupée : 3039928036o pour 872 éléments sur taille maximale 52157218816o

Citation:

C:\ - Taille occupée : 4093830o pour 2 éléments sur taille maximale 7731150848o
D:\ - Taille occupée : 0o pour 0 éléments sur taille maximale 27151826944o
E:\ - Taille occupée : 238695o pour 2 éléments sur taille maximale 27151826944o
Code:

1 2 Result := ReadInteger('MaxCapacity'); Result := Result * 1024 * 1024;
ne donne pas la même chose que

Code:

Result := ReadInteger('MaxCapacity') * 1024 * 1024;

Même pas un warning sur la possibilité que Integer * 1024 * 1024 est calculé en Integer et pas en Int64 le type de Result :aie:
30/01/2022, 00h37
castorcharly
Merci à tous pour vos recherches et propositions.

Shai,

Ta solution est complète et tes tests sont concluants, mais tu as surement une version plus récente que la mienne.
Dans les déclarations d'API je n'ai pas GetVolumeNameForVolumeMountPoint ni la W d'ailleurs, donc j'ai regardé sur msdn
et j'ai trouvé cette API. Et là je nage un peu, mais je coule beaucoup...

Comme tu l'indiques, il y aurait un bug dans le passage des params, mais quand je vois la déclaration MSDN c'est bien un LPCWSTR pour le premier param:
Code:

1 2 3 4 5 BOOL GetVolumeNameForVolumeMountPointW( [in] LPCWSTR lpszVolumeMountPoint, [out] LPWSTR lpszVolumeName, [in] DWORD cchBufferLength );
Donc tu pourrais m'en dire plus, car j'ai tenté différentes possibilité, mais j'ai une violation à chaque fois sur l'appel.
As tu modifié la déclaration dans les sources, pour faire un truc comme:

Code:

function GetVolumeNameForVolumeMountPointW(lpszVolumeMountPoint: LPCSTR; lpszVolumeName: LPWSTR; cchBufferLength: DWORD): boolean; external Kernel32 name 'GetVolumeNameForVolumeMountPointW';

Ou autrement ?
Peut être me passer leur déclaration ?

En tout cas merci encore
30/01/2022, 12h58
ShaiLeTroll

Je n'ai pas modifié la déclaration, j'ai triché avec le PByte uniquement
c'est D10 Seatle

Code:

function GetVolumeNameForVolumeMountPointW(lpszVolumeMountPoint: LPCSTR; lpszVolumeName: LPSTR; cchBufferLength: DWORD): BOOL; stdcall; external kernel32 name 'GetVolumeNameForVolumeMountPointW';

Compatible avec cet appel

Code:

if GetVolumeNameForVolumeMountPoint(PAnsiChar(PByte(C + ':\')), @VolumeName[0], MAX_PATH) then

stdcall est nécessaire si compilation en 32Bits
En 64bits, tout est en fastcall64 normalement et cela n'a pas d'impact de mettre la convention, du moins en théorie.
BOOL aussi c'est LongBool à 4 octets contrairement à Boolean sur une seul octet, cela ne doit pas aimer non plus

Effectivement je tenterais la bonne déclaration

Code:

function _GetVolumeNameForVolumeMountPoint (lpszVolumeMountPoint: LPCWSTR; lpszVolumeName: LPWSTR; cchBufferLength: DWORD): BOOL; stdcall; external kernel32 name 'GetVolumeNameForVolumeMountPointW';

avec cet appel

Code:

if _GetVolumeNameForVolumeMountPoint(PChar(C + ':\'), @VolumeName[0], MAX_PATH) then

De toute façon, cela ne compile pas si l'on mélange les types, donc un nom de fonction différent pour anticiper un jour le passage sur un Delphi plus récent et un conflit de déclarations

quand je déclare moi même une API j'ai tendance à tricher encode d'avantage :)
Code:

1 2 function GetVolumeNameForVolumeMountPoint (const lpszVolumeMountPoint: string; lpszVolumeName: LPWSTR; cchBufferLength: DWORD): BOOL; stdcall; external kernel32 name 'GetVolumeNameForVolumeMountPointW';
une string constante est totalement compatible avec un PChar comme paramètre en entrée, la DLL va la traiter de toute façon comme un PChar sans y toucher.
pour le second paramètre c'est possible aussi mais c'est plus "risqué" vu que la DLL va remplir la variable sans tenir compte du compteur COW (Copy on Write) donc c'est plus prudent de rester sur du PChar

30/01/2022, 16h15
ShaiLeTroll

La String const, je l'ai déjà fait mais j'avoue ne pas trop osé quand même car c'était surtout à l'époque de Brldmm.dll entre mes DLL et que je faisais un peu ça au petit bonheur la chance :mouarf:
30/01/2022, 20h38
Paul TOTH

Citation:

Envoyé par ShaiLeTroll

La String const, je l'ai déjà fait mais j'avoue ne pas trop osé quand même car c'était surtout à l'époque de Brldmm.dll entre mes DLL et que je faisais un peu ça au petit bonheur la chance :mouarf:

ah oui mais là c'est juste une simplification d'écriture...côté exe on utilise généralement des strings et pour les passer à une API on les converti en PChar...mais comme il n'y a pas de différence technique entre une "const string" et un PChar - vu que les chaînes possèdent toujours un #0 terminal - le fait de déclarer un const string évite simplement le transtypage...mais côté DLL c'est bel est bien un PChar, il n'est pas question de le traiter comme un string avec son compter de référence car cela obligerait en effet à embarquer ShareMem pour partager le gestionnaire de mémoire et rendrait l'API dépendante de Delphi...et d'ailleurs là c'est une API Windows qui attend un PChar qui ne sera jamais considérer comme un string Delphi.
31/01/2022, 11h28
castorcharly

Bonjour,

Merci, en fait je faisais une erreur ailleurs dans mon code qui me provoquait cette violation, le sdtcall était mal placé :oops:
Je pouvais chercher dans tous les sens comment passer mes pointers,

Là ça marche nickel merci pour cette solution