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 what's there, I've 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:\Foo\MyFile.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. Here's what I've 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 file's 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, you'll 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