XProfan

- Seite 1 -

Dank der Hilfe von Roland und iF habe ich jetzt die Information über die Grösse des Windows-Papierkorb - OK - aaaaaber kann man auch die aktuelle Grösse des Papierkorbes feststellen, wenn in diesem schon gelöschte Daten vorhanden sind ??

Jörg
Sellmeyer

Probier mal das:
Kompilieren Markieren Separieren

!
ChDir "C:Recycler"WinXP
ChDir "C:Recycled"Win9x
AddFiles *"*"
ListBox$("",2)

Es gibt bestimmt auch noch einen Registryeintrag, wo man den Pfad auslesen kann.

Gruß
Jörg

Windows XP SP2 XProfan X4
... und hier mal was ganz anderes als Profan ...

- Seite 2 -

Hallo Jörg
Dein Code zeigt mir den Inhalt des Ordners (Normalzustand: versteckt) an - das sind in 3 Ordnern 5 Dateien. (*.info + *.txt) Der eigentliche Inhalt des Papierkorbes muss sich aber irgendwo anders verstecken und da bin ich überfragt. (zu blöd

)

Nicht zu blöd => die Sache ist undokumentiert.
Im Papierkorb gibt es eine Datei INFO (bzw. INFO2) die die Dateiinformationen des Papierkorbs enthält - u.a. auch die Größe.

Vielleicht hilft das ja schon weiter...
[quote:3af1232b6e]
From: Daniel U. Thibault Subject: Recycling Bin internals Date: 16 Jul 1999 00:00:00 GMT Message-ID: <378F60AD.E938B0EE@DREV.DND.Ca> Content-Transfer-Encoding: 8bit X-Accept-Language: en,fr Content-Type: text/plain; charset=iso-8859-1 Organization: Centre de recherches pour la =?iso-8859-1?Q?d=E9fense?=, Valcartier Mime-Version: 1.0 Reply-To: Thibault, Daniel U. Newsgroups: borland.public.delphi.winapi A long time ago, Steve Schafer wrote: > The internal operation of the Recycle Bin is mostly undocumented, but article > Q136517 in the Microsoft KnowledgeBase has a little bit of information. In addition > to whats there, Ive discovered the following: > The files in the RECYCLED directory (there is one on each drive) contain each of > the files in the bin, with their original names replaced by new names of the form > D. > where is just the letter of the drive (A, B, C or whatever), number> is just an integer, and is the original file extension. So, for > example, D:FooMyFile.doc will, when deleted, be moved to the RECYCLED > directory on drive D and renamed to something like DD3.doc. > > There are two additional files in the RECYCLED directory. The first is DESKTOP.INI, > whose sole purpose seems to be to provide a timestamp indicating when the > Recycle Bin was last emptied. The other file is called INFO (no extension), and it is > this file that contains all of the useful information you would need to restore > deleted files. > > INFO consists of a 20-byte header followed by one 280-byte record for each file > that has been deleted. The header consists of five 32-bit integers: > > bytes 0- 3: seems to always be zero; version number? > bytes 4- 7: number of files in the Recycle Bin > bytes 8-11: next sequence number to use > bytes 12-15: = 280 (size of deleted file records) > bytes 16-19: total number of bytes occupied by deleted files > > Each deleted-file record consists of 260 bytes containing the full null-terminated > path name of the deleted file, followed by a 20-byte trailer: > > bytes 0- 3: sequence number for this file > bytes 4- 7: drive letter for this file (A=0, B=1, etc.) > bytes 8-15: time when file was deleted, in FILETIME format > bytes 16-19: number of bytes occupied by this file > > The numbers that specify the number of bytes occupied by deleted files includes > the cluster overhead; that is, a 1-byte file on a drive that uses 8192-byte clusters > is reported as occupying 8192 bytes. > > It appears that if several files are deleted during a single > operation, they will all have the same deletion time stamp. You could use this > information to determine the granularity of your undo operations. > > The above applies to FAT partitions under the original Win95, and also Win95 OSR2. > The later versions of Win95 that have the new IE shell use a different structure for > the INFO file (which is now called INFO2). NT 4.0 also uses a different structure, > partly because it stores file names in Unicode. In any case, the basic idea seems to > be the same; just the details are different. The four bytes that I mentioned above > might be the version number are different for the different formats. Heres what Ive found out about the FAT32 Win95 recycling bin Info2 file structure: The Info2 header consists of five 32-bit integers: bytes 0- 3: seems to always be $00000004 bytes 4- 7: definitely NOT the number of files in the Recycle Bin bytes 8-11: definitely NOT the next sequence number to use bytes 12-15: = 280 (size of deleted file records) bytes 16-19: total number of bytes occupied by deleted files?? (The figure reads about 8 times too large, even when considering the cluster size...) Each deleted-file record consists of 260 bytes containing the full null-terminated path name of the deleted file, followed by a 20-byte trailer: bytes 0- 3: sequence number for this file bytes 4- 7: drive letter for this file (A=0, B=1, etc.) bytes 8-15: time when file was deleted, in FILETIME format bytes 16-19: number of bytes occupied by this file (a whole multiple of the cluster size) Under WinNT, the structure of Info is changed in only one regard: Each deleted file record is 2*MAX_PATH bytes longer because the 20-byte trailer is followed by the files fully qualified name and path in Unicode. The Info header version integer also reads as $00000002. What I need help with is this: Under WinNT, the Info file and the deleted files end up in a sub-directory of RECYCLER (*not* RECYCLED, youll have noticed) that bears a long and weird name. Is this name always the same or does it obey to some hash function? Does RECYCLER ever contain more than one of these strange sub-dirs? Is this peculiar to HPFS? Daniel U. Thibault a.k.a. Urhixidur a.k.a. Sire Bohémond de Nicée
[/quote:3af1232b6e]

Michael
Wodrich

Ich habe das Zitat mal durch den Übersetzer gejagt:[quote:ec0837dda4]
Von : Daniel U. Thibault Unterwirft: Wiederverwertung des Behälters internals Datum: Am 16. Juli 1999 00:00:00-WEZ-Nachrichtenpersonalausweis: <378F60AD.E938B0EE@DREV.DND.Ca> Zufriedene Übertragungsverschlüsselung: 8-Bit-X-Accept-Language: en, fr Zufriedener Typ: Text/Ebene; charset=iso-8859-1 Organisation: Stehen Sie Im Mittelpunkt de gießen recherches la =? Iso-8859-1? Q? d=E9fense? =, Valcartier Pantomime-Version: 1.0 Antwort-: Thibault, Daniel U. Newsgroups: Borland.public.delphi.winapi Vor langer Zeit schrieb Steve Schafer:> wird Die interne Operation des Papierkorbs größtenteils undokumentiert, aber Artikel> Q136517 im Microsoft, das KnowledgeBase ein kleines bisschen der Information hat. Außerdem> dazu, was dort ist, habe ich den folgenden entdeckt:> Die Dateien im WIEDERVERWANDTEN Verzeichnis (gibt es ein auf jedem Laufwerk) enthalten jeden> die Dateien im Behälter, mit ihren ursprünglichen Namen ersetzt durch neue Namen der Form> D.>, wo gerade der Buchstabe des Laufwerkes (A, B, C oder was für) ist, ist Anzahl> gerade eine ganze Zahl, und ist der ursprüngliche Dateinamenszusatz. Also, für> Beispiel wird D:FooMyFile.doc, wenn gelöscht, zum WIEDERVERWANDTEN> Verzeichnis auf dem Laufwerk D bewegt und zu etwas wie DD3.doc umbenannt.>> gibt Es zwei zusätzliche Dateien im WIEDERVERWANDTEN Verzeichnis. Das erste ist DESKTOP.INI,>, wessen alleiniger Zweck scheint zu sein, um einen Zeitstempel zur Verfügung zu stellen, der anzeigt, als> Papierkorb entleert letzt war. Die andere Datei wird INFO (keine Erweiterung) genannt, und es ist> diese Datei, die die ganze nützliche Information enthält, die Sie> gelöschte Dateien würden wieder herstellen müssen.>> besteht INFO aus einem 20-Byte-Kopfball gefolgt von einer 280-Byte-Aufzeichnung für jede Datei>, der gelöscht worden ist. Der Kopfball besteht aus fünf ganzen 32-Bit-Zahlen:>> Bytes 0-3: Scheint immer Null zu sein; Versionsanzahl?> Bytes 4-7: Anzahl von Dateien im Papierkorb> Bytes 8-11: folgende Folge-Anzahl,> Bytes 12-15 zu verwenden: = 280 (Größe von gelöschten Dateiaufzeichnungen)> Bytes 16-19: Die Gesamtzahl von Bytes besetzt durch gelöschte Dateien>> Jede Aufzeichnung der löschen-Datei besteht aus 260 Bytes, die das volle mit der Null begrenzt> Pfadname der gelöschten Datei, gefolgt von einem 20-Byte-Trailer enthalten:>> Bytes 0-3: Folge-Anzahl für diese Datei> Bytes 4-7: Laufwerksbuchstabe für diese Datei (A=0, B=1, usw.)> Bytes 8-15: Zeit, als Datei, im FILETIME-Format> Bytes 16-19 gelöscht wurde: Die Anzahl von Bytes besetzt durch diese Datei>> Die Anzahlen, die die Anzahl von durch gelöschte Dateien besetzten Bytes angeben, umfasst> die Traube oben; d. h. eine 1-Byte-Datei auf einem Laufwerk, der 8192-Byte-Trauben> verwendet, wird als das Besetzen von 8192 Bytes berichtet.>> scheint Es, dass, wenn mehrere Dateien während einer Single> Operation gelöscht werden, sie alle dieselbe Auswischen-Zeitmarke haben werden. Sie konnten das> Information verwenden, um die Körnung von Ihrem zu bestimmen, Operationen aufmachen.>> gilt Der obengenannte an FETTE Teilungen unter dem ursprünglichen Win95, und auch Win95 OSR2.> Die späteren Versionen von Win95, die den neuen Nutzen D. H. Schale-Gebrauch eine verschiedene Struktur für> die INFO-Datei haben (der jetzt INFO2 genannt wird). NT 4.0 auch Gebrauch eine verschiedene Struktur,> teilweise, weil es Dateinamen im Unicode speichert. Jedenfalls scheint die Grundidee>, dasselbe zu sein; gerade sind die Details verschieden. Die vier Bytes, die ich oben> erwähnte, könnten sein die Versionsanzahl ist für die verschiedenen Formate verschieden. Hier ist, was ich vom FAT32 Win95 Wiederverwertung des Behälters Info2 Dateiaufbau erfahren habe: Der Info2 Kopfball besteht aus fünf ganzen 32-Bit-Zahlen: Bytes 0-3: Scheint immer Bytes von 00000004 $ 4-7 zu sein: bestimmt NICHT die Anzahl von Dateien in den Papierkorb-Bytes 8-11: bestimmt NICHT die folgende Folge-Anzahl, Bytes 12-15 zu verwenden: = 280 (Größe von gelöschten Dateiaufzeichnungen) Bytes 16-19: Gesamtzahl von durch gelöschte Dateien besetzten Bytes?? (Die Zahl liest zu große ungefähr 8mal, selbst wenn, die Traube-Größe ... betrachtend), Jede Aufzeichnung der löschen-Datei aus 260 Bytes besteht, die die volle mit der Null begrenzte Pfadname der gelöschten Datei, gefolgt von einem 20-Byte-Trailerenthalten: Bytes 0-3: Folge-Anzahl für diese Dateibytes 4-7: Laufwerksbuchstabe für diese Datei (A=0, B=1, usw.) Bytes 8-15: Zeit, als Datei, in FILETIME-Format-Bytes 16-19 gelöscht wurde: Anzahl von durch diese Datei besetzten Bytes (ein ganzes Vielfache der Traube-Größe) Unter WinNT wird die Struktur des Infos in nur einer Rücksicht geändert: Jede gelöschte Dateiaufzeichnung ist 2*MAX_PATH längere Bytes, weil dem20-Byte-Trailer vom völlig qualifizierten Namen der Datei und Pfad im Unicode gefolgt wird. Die ganze Info-Kopfball-Versions-Zahl liest auch als 00000002 $. Was ich brauche, dass Hilfe damit das ist: Unter WinNT enden die Info-Datei und die gelöschten Dateien in einem Unterverzeichnis von RECYCLER (*not* WIEDERVERWANDT, Sie werden bemerkt haben), der einen langen und unheimlichen Namen trägt. Ist dieser Name immer dasselbe, oder folgt es etwas Kuddelmuddel-Funktion? Enthält RECYCLER jemals mehr als einen dieser fremden sub-dirs? Ist das HPFS eigenartig? Daniel U. Thibault a.k.a. Urhixidur a.k.a. Vater Bohémond de Nicée[/quote:ec0837dda4]
Schöne Grüße
Michael Wodrich

Programmieren, das spannendste Detektivspiel der Welt.

Hi Michael
Mir brummt der Schädel (Kopfball)

Hi Horst - wenn ich Zeit habe, übersetze ich es dir gerne...

Hallo Andreas
Danke für Dein Angebot. Soweit ich das jetzt begriffen habe, kann man die Datenmenge der im Papierkorb schlummernden Dateien nicht feststellen und das ist traurig, traurig, traurig

- Vielleicht findet man aber in einer korrekten Übersetzung doch noch einen Hinweis. Wäre Dir also sehr dankbar für Deine Mühe

Natürlich kann man das feststellen - auch welche Dateien da drin sind.
Die Gefahr: Es ist undokumentiert, d.h. es kann sich bei anderen Systemen laufen an der Art, wie das gespeichert wird, etwas ändern - möglich ist es aber...

Sucht mal im PSDK oder MSDN nach SHQueryRecycleBinA und nach der SHQUERYRBINFO
Structure. Ich hoffe das hilft

Das war ein guter Tipp, so in etwa geht:
Kompilieren Markieren Separieren

Def @SHQueryRecycleBin(2) !"SHELL32.DLL","SHQueryRecycleBinA"
Def @GetLastError(0) !"KERNEL32","GetLastError"
Def @SetLastError(1) !"KERNEL32","SetLastError"
Windowstyle 31
WindowTitle "Papierkorbgröße ermitteln"
Window 0,0-640,440
Declare ROOT$,SHQUERYRBINFO#,API&
Decimals 0
LET ROOT$="C:"
DIM SHQUERYRBINFO#,20
Long SHQUERYRBINFO#,0=20
@SetLastError(0)
Print @SHQueryRecycleBin(@ADDR(ROOT$),SHQUERYRBINFO#)
LET API&=@GetLastError()
Print "API-Fehler: "+@STR$(API&)
Print "Größe des Papierkorbs: "+@STR$(@LONG(SHQUERYRBINFO#,4))+" Bytes"
Print "Anzahl der Dateien: "+@STR$(@LONG(SHQUERYRBINFO#,12))
Dispose SHQUERYRBINFO#

While 0=0

    Waitinput

wend

Da die Zahlen in der Struktur 64-Bit Zahlen sind, müßte normalerweise eine korrekte Umrechnung vorgenommen werden - das überlasse ich jetzt den anderen.