On Sat, 6/28/2025 4:29 PM, micky wrote:
In alt.comp.os.windows-10, on Sat, 28 Jun 2025 22:18:45 +0200, "Carlos
E.R." <robin_listas@es.invalid> wrote:
On 2025-06-28 21:54, micky wrote:
In win11, but maybe win10 too, since I didn't have the same setup, I
find that files I've sent to the Recycle Bin, are actually sent to a USB >>> hard drive, G:? There is only one Recycle Bin icon and its window
doesn't say where things are kept.
Are all the recycled files there?
I mean, there could be one folder on each disk, although there is a
single icon for all of them.
I think the list of G: was a phantom list, because I deleted everything
from the Receylcle Bin when the power was turned off to G: and when I
turned the power on again, there was nothing in either Recycle file
The advantage of one folder on each disk is that moving stuff there is
very fast, only the directory entry is rewritten, the file blocks do not
move.
Come to t hink of it, the files on the list were never on G: in the
first place. They were on C:. Why they were listed in $RECYCLE.BIN on
the G: drive may be a mystery!
But I am not sure if Windows is using this strategy.
You know the design has to be based on "move' and not "copy".
Imagine if you were deleting a 100GB file. You would not want
the file moved from volume to volume (copy). The fake-delete has to be
faster than that, so a "move origname newname" is the easiest way to move it out of the way.
By putting all the files into a "single big bucket", what is the
danger ? File Name collision. When the file is moved, the name gets
changed. and it must be changed in a way, where two files tossed
in the trash, don't overwrite one another (on the move attempt).
Some of the elements of the scheme are bound to make sense.
What other things do we know ?
Storage devices can be "Fixed" or "Removable". The USB stick determines
this, via the RMB bit. Some Sony USB drives are "fixed". Most other brands would be "Removable". The delete-behavior on a Removable stick is different.
When I create a brand new "Basic" drive (Fixed) in Disk Management,
this is some of what I see.
.\nfi.exe F: > F:\nfi-F-out.txt # Formatted NTFS, I will list it, and store it on itself
File 36
\System Volume Information
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$INDEX_ROOT $I30 (resident)
File 37
\System Volume Information\WPSettings.dat
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (resident)
File 38
\$RECYCLE.BIN
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$INDEX_ROOT $I30 (resident)
File 39
\$RECYCLE.BIN\S-1-5-21-1111111111-2222222222-3333333333-1001 <=== A user SID. Multiple of these can be created,
$STANDARD_INFORMATION (resident) as the device is used on different computers
$FILE_NAME (resident) with a different OS install and user-sid
$INDEX_ROOT $I30 (resident)
File 40 \$RECYCLE.BIN\S-1-5-21-1111111111-2222222222-3333333333-1001\desktop.ini
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (resident)
File 41
\nfi-F-out.txt <=== the file listing, is stored on the drive itself, for this example
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 49712-49727 (0xc230-0xc23f) <=== 16 sectors is 2 clusters storage
That's how you gather information about underlying structure,
with the assurance the tool can't see everything (a library control file
can be seen, but not a library projection, nor can a trash projection
be seen in a practical way, but the *ingredients* used to make trashes
are there.
I've just thrown the file list file, in the trash bucket, upper left.
Now I will rerun the listing of F. And see if I can spot "new trash".
File 36
\System Volume Information
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$INDEX_ROOT $I30 (resident)
File 37
\System Volume Information\WPSettings.dat
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (resident)
File 38
\$RECYCLE.BIN
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$INDEX_ROOT $I30 (resident)
File 39
\$RECYCLE.BIN\S-1-5-21-1111111111-2222222222-3333333333-1001
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$INDEX_ROOT $I30 (resident)
File 40 \$RECYCLE.BIN\S-1-5-21-1111111111-2222222222-3333333333-1001\desktop.ini
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (resident)
File 41 \$RECYCLE.BIN\S-1-5-21-1111111111-2222222222-3333333333-1001\$RU1CCI7.txt # File 41 from previous listing, has a new home.
$STANDARD_INFORMATION (resident) # It is renamed and in the trash. 2 clusters.
$FILE_NAME (resident) # The Filenum value did not change.
$DATA (nonresident)
logical sectors 49712-49727 (0xc230-0xc23f)
File 42 \$RECYCLE.BIN\S-1-5-21-1111111111-2222222222-3333333333-1001\$IU1CCI7.txt # It's "mate" is so small, it fits in
$STANDARD_INFORMATION (resident) # the 1024 byte $MFT entry.
$FILE_NAME (resident)
$DATA (resident)
File 43
\nfi-F-out.txt # This is the new file being copied
$STANDARD_INFORMATION (resident) # to make this example text. Still 2 clusters long.
$FILE_NAME (resident) 3 I "threw away File 41", and made a new File 43.
$DATA (nonresident)
logical sectors 49728-49743 (0xc240-0xc24f)
This is the $IU1CCI7.txt "partner" file, to the thing deleted.
It contains a pointer to where the item belongs on a "restore from trash" :-) Which is F:\\nfi-F-out.txt
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 02 00 00 00 00 00 00 00 90 1A 00 00 00 00 00 00 ................ 00000010 10 3D AF B5 A5 E8 DB 01 11 00 00 00 46 00 3A 00 .=¯µ¥èÛ.....F.:.
00000020 5C 00 6E 00 66 00 69 00 2D 00 46 00 2D 00 6F 00 \.n.f.i.-.F.-.o. 00000030 75 00 74 00 2E 00 74 00 78 00 74 00 00 00 u.t...t.x.t...
That "Fixed" device then, has its own $RECYCLE.BIN structure.
The "projection" in the upper left corner of the desktop,
it reads the state of all the $RECYCLE.BIN and gives an
overall view. But the thing deleted on F: , stays on F: ,
until deleted, or restored.
Paul
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)