detecting files that arent actually there

[klepp0906]

So i've been on a hunt to eliminate some rogue desktop.ini files. I have about half a dozen non system drives set up and all but 1 of them ive pared them down to a single desktop.ini which is the one paired with my SID/recreated from the $RECYCLE.BIN folder if its deleted.

That 1 drive im referring to is showing about a half a dozen of them, one of them is the one that should be there.. the rest i get "unable to delete the file was not found, or the filename is invalid or too long."

ive tried clicking the rebuild the database button and it still picks them up. ive tried using an admin cmd to rd /s /q and it says cannot find path specified.

theyre literally not there and everything thinks they are.

any ideas?

[void]

The Windows Shell cannot see this Desktop.ini file.

Windows Explorer will recreate this Desktop.ini file immediately after deletion.

Not the cleanest solution... However, the following worked for me:

• Select your Desktop.ini in the $recycle.bin folder.
• Press F2
• Rename the Desktop.ini to:

  Code: Select all

  01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890.txt

• Because the full path and filename is longer than 259 characters, Everything will bypass the Windows Shell rename dialog and rename the file with low level WINAPI calls.
• Search for:

  Code: Select all

  01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890.txt

• Select this file.
• Hold down Shift and press Delete.
• Because the full path and filename is longer than 259 characters, Everything will bypass the Windows Shell delete dialog and delete the file with low level WINAPI calls.

After renaming the Desktop.ini to 0123456789....txt a new Desktop.ini file is not automatically recreated.

[klepp0906]

thank you, on it!

[klepp0906]

okay, so heres my issue, if i browse directly to those folders... theres nothing there TO rename.

here's what all my "normal" drives are looking like

1.jpg (54.6 KiB) Viewed 2596 times

here is what the problem drive is displaying (and to be clear i use drivepool in case thats relevant but ive already also checked each individual mounted disk)

2.jpg (114.76 KiB) Viewed 2596 times

here is what happens when i try to delete doubles or phantom items

3.jpg (80.79 KiB) Viewed 2596 times

its literally just this one drive, i just tried disabling indexing of offline volumes as well thinking perhaps it was a remnant but no luck there either.

[klepp0906]

if i go back up a directory it shows 2 $recycle.bin folders in the root of E:

if i use elevated cmd to

Code: Select all

rd /s /q E:\$RECYCLE.BIN

it will remove one of them, it will leave what is presumably the problem one causing all of this as if i try to access it i get "windows cannot find..."

its somehow stuck in everything when its not anywhere to be found.

even a

Code: Select all

dir /a:h

will not show anything yet there it is in voidtools O.O

[klepp0906]

so i tried the method you linked to in the other thread. its not doing it because as far as windows is concerned, it is literally not there.

4.jpg (158.94 KiB) Viewed 2546 times

as you can see, no $RECYCLE.BIN folder whatsoever because i deleted it. well, deleted the normal functioning one anyhow. left with the phantom one that nothing but everything sees.

does that not point to a bug? I'm using the 1.5 alpha if that could be relevant?

[void]

How are you indexing your E: drive?

Could you please send your Tools -> Debug -> Statistics to support@voidtools.com

[klepp0906]

i got it sorted. finally. user error more or less. how exhausting.

so if you recall, you helped me get everything as set up as it can be for working with drivepool. well I have two pools. one wasnt presenting the issue for whatever reason. the problem one i had deleted all the $recycle.bin folders from the root of each of the drives in the pool. however, there were $recycling.bin files inside some of the .poolpart folders as well. this was the source of the hang up.

not sure why it was this way on one pool and not the other, also not sure how or why windows nor everything could open it or interact with it, or in windows case see it at all from the command line.

still i started perusing the poolpart folders and inside one of them was the offender.

sorry for wasting your time. that being said, i did learn something useful at least. that robocopy trick would have saved me a real headache about a month ago when i didnt exclude junctions from the user folder and ended up with a path so long windows couldnt do anything with it. ended up having to format the backup drive and run a fresh backup to it over that mess ;p