Curious error message!

I have a 4TB HDD (Seagate) external to the main computer connected to
a PCI slot via a USB3.

Recently my computer crashed and was restored from backup.

Now I'm getting...

"The Recycle Bin on P:\ is corrupted. Do you want to empty the Recycle
Bin for this drive?"

Is this a fault of the external 4TB HDD, or the main OS?

Peter Jason wrote:
I have a 4TB HDD (Seagate) external to the main computer connected to
a PCI slot via a USB3.

Recently my computer crashed and was restored from backup.

Now I'm getting...

"The Recycle Bin on P:\ is corrupted. Do you want to empty the Recycle
Bin for this drive?"

Is this a fault of the external 4TB HDD, or the main OS?


Their recipe here, is to remove the recycle bin from
each partition. And the system will create a new one afterwards,
on each partition where you then try to delete stuff. Generally,
most Windows utilities croak if they hit reparse points, so
I assume there is some degree of safety if trying this. But
this uses delete commands !!! so what do I know :-(

http://www.thewindowsclub.com/recycl...rupted-windows

You will notice as well, in the comment section, the users
are running into permission problems. Even as administrator,
it's all to easy to get Access Denied.

Also in the comment section, are some dopey *******s. Like
the individual who crafted this plumb. Of course it can
delete all the files on E:

rd /s /q E:

when the command was supposed to be

rd /s /q E:\$Recycle.bin

Actually, the /q is for "Quiet" or "Don't Prompt Me".
It might be better to be prompted, as to what to remove.
It really depends on how many files are in the various
recycle bins, as to how long it's going to take to
remove all the $Recycle.bin occurrences on the machine.

At a minimum, I would want to make sure every volume
is CHKDSK-clean, before removing stuff. The OS is
supposed to be doing that for you, in the background.
But you can do it anyway.

The file name length bug has been fixed in Windows 10.
On the older OSes, a process like "Firefox" could
make a filename of max_length. But File Explorer cannot
move or delete such files. If such a file ended up in
the recycle bin, it cannot be removed. Well, that situation
should no longer arise in Windows 10. File Explorer now
works with max_length files. That remains a problem with
at least some of the older OSes (I tested that at one time).

*******

This does all partitions in one shot. Does it
work in your situation ? Dunno.

http://www.nirsoft.net/utils/nircmd.html

nircmd emptybin

Naturally, the command can only work if it has permission.

An ordinary Command Prompt, is "owned by you".

A "Run as Administrator" Command Prompt, runs as administrator,
which isn't all that powerful.

However, using a Run as Administrator Command Prompt and then
running this from it, gives a System Account window to work in.

https://docs.microsoft.com/en-us/sys...wnloads/psexec

[In first administrator window, assumes psexec sits in Downloads folder
You must belong to the administrator group, to use "impersonation"
to become the system account.]

cd /d %userprofile%\Downloads

psexec -hsi cmd

[In the second window that opens]

whoami # Verify you're "SYSTEM" account now!!!

cd /d %userprofile%\Downloads # navigate to your copy of "nircmd"
# Verify you're actually in your account
# home directory, and not somewhere else.

nircmd emptybin

*******

HTH,
Paul

In article , lid says...
The file name length bug has been fixed in Windows 10.
On the older OSes, a process like "Firefox" could
make a filename of max_length. But File Explorer cannot
move or delete such files. If such a file ended up in
the recycle bin, it cannot be removed. Well, that situation
should no longer arise in Windows 10.


That happened to me yesterday. On Win 10

Jason wrote:
In article , lid says...
The file name length bug has been fixed in Windows 10.
On the older OSes, a process like "Firefox" could
make a filename of max_length. But File Explorer cannot
move or delete such files. If such a file ended up in
the recycle bin, it cannot be removed. Well, that situation
should no longer arise in Windows 10.


That happened to me yesterday. On Win 10

Was the file length exactly max_length, a lot more
than max_length, or what ?

There was a note about Win10 gaining support (finally)
for really long path names (corresponds to the second
ref below). Supposedly corresponding to some previous
documentation to that effect (that we could never prove),
that NTFS could support really long paths. But it's
the usual thing, of no proof it works, and what tools
do you use to prove it.

https://en.wikipedia.org/wiki/Ntfs

File names are limited to 255 UTF-16 code units.

The NT kernel limits full paths to 32,767 UTF-16 code units.

https://msdn.microsoft.com/en-us/lib...ng_conventions

In the Windows API... MAX_PATH... is defined as 260 characters.

So which is it, 260 or 32767 ? And so on.

The typical scenario with the max_length problem,
is a program like Firefox has no problem working
with the file system directly, to make a max_length
filename. Then, on OSes where File Explorer can only
handle max_length-1, you have a problem moving or
deleting the file. It simply refuses all operations.

In some cases, what the user is trying to do, is
grossly exceed the path length. And a
SUBST approach

http://www.vfrazee.com/ms-dos/6.22/help/subst.htm

can be used to make a fake drive letter, to "shorten"
part of the path name while working.

*******

For my previous max_length experiments, I was using
ActiveState PERL (runs in Windows), to experiment
with making paths. In theory, that environment should
also work if needing to delete a filename directly.
Of course, PERL is also an irritating language to
work in, and you need to keep your two manuals handy
at all times. That is, unless you constantly work
in PERL or something, and have memorized the whole thing.

*******

I'll see if my little PERL script is still around somewhere
and give this a test again later. First I have to remember
the script name :-) and what disk I might have left it on.

Paul

get the free app

Owner

or whatever it is called and run it on the Bin.

M$ controls the horizontal, controls the vertical and controls you life !!!

Kick them in the ass by freeing up your system and take charge.
Don't wimp out.

In article ,
says...

I have a 4TB HDD (Seagate) external to the main computer connected to
a PCI slot via a USB3.

Recently my computer crashed and was restored from backup.

Now I'm getting...

"The Recycle Bin on P:\ is corrupted. Do you want to empty the Recycle
Bin for this drive?"

Is this a fault of the external 4TB HDD, or the main OS?

Anything in the recycle bin you want back? If not then do it else I
dunno guess it depends upon are files copyable or restoreable and what
you end up with if you try ...

Paul wrote:
Jason wrote:
In article , lid says...
The file name length bug has been fixed in Windows 10.
On the older OSes, a process like "Firefox" could
make a filename of max_length. But File Explorer cannot
move or delete such files. If such a file ended up in
the recycle bin, it cannot be removed. Well, that situation
should no longer arise in Windows 10.

That happened to me yesterday. On Win 10

Was the file length exactly max_length, a lot more
than max_length, or what ?

There was a note about Win10 gaining support (finally)
for really long path names (corresponds to the second
ref below). Supposedly corresponding to some previous
documentation to that effect (that we could never prove),
that NTFS could support really long paths. But it's
the usual thing, of no proof it works, and what tools
do you use to prove it.

https://en.wikipedia.org/wiki/Ntfs

File names are limited to 255 UTF-16 code units.

The NT kernel limits full paths to 32,767 UTF-16 code units.


https://msdn.microsoft.com/en-us/lib...ng_conventions


In the Windows API... MAX_PATH... is defined as 260 characters.

So which is it, 260 or 32767 ? And so on.

The typical scenario with the max_length problem,
is a program like Firefox has no problem working
with the file system directly, to make a max_length
filename. Then, on OSes where File Explorer can only
handle max_length-1, you have a problem moving or
deleting the file. It simply refuses all operations.

In some cases, what the user is trying to do, is
grossly exceed the path length. And a
SUBST approach

http://www.vfrazee.com/ms-dos/6.22/help/subst.htm

can be used to make a fake drive letter, to "shorten"
part of the path name while working.

*******

For my previous max_length experiments, I was using
ActiveState PERL (runs in Windows), to experiment
with making paths. In theory, that environment should
also work if needing to delete a filename directly.
Of course, PERL is also an irritating language to
work in, and you need to keep your two manuals handy
at all times. That is, unless you constantly work
in PERL or something, and have memorized the whole thing.

*******

I'll see if my little PERL script is still around somewhere
and give this a test again later. First I have to remember
the script name :-) and what disk I might have left it on.

Paul

I used my little rename.pl script, and this is the
largest file I could make. The filename part is 256
characters = 255 + NULL. The path makes it a bit longer.

https://msdn.microsoft.com/en-us/lib...47(VS.85).aspx

"the maximum path on drive D is "D:\some 256-character path stringNUL"
where "NUL" represents the invisible terminating null character
for the current system codepage."

Directory of F:\

11/13/2017 11:27 PM 0 F:\01234567890123456789012345678901234567890123456 789
01234567890123456789012345678901234567890123456789
01234567890123456789012345678901234567890123456789
01234567890123456789012345678901234567890123456789
01234567890123456789012345678901234567890123456789 0.txt

An attempt to make a filename one character longer fails.
In Windows 10, I can delete the working sample file in the recycle bin.
In older OSes, I couldn't, and needed to use the rename(a,b)
function in perl to do it (make the filename short enough so
it could be deleted).

I tried adding a directory to the path, as in this idea

F:\0123456789\0123456789012345678901234567890.txt

and the additional path subtracts from the filename allowed.

This is my original rename.pl script, just a toy to play with
while ActiveState Perl is installed. It has some conceptual
errors in it, and this is only for historical reference.
For example, the string I print on the screen, didn't need
the added slash, and could have done without that. It throws
the character count off too :-) It's easier to see what
the script created by me just using the dir command, to be
doubly sure later.

http://pastebin.com/mh3hky75

*******

In conclusion, I cannot understand your symptoms right
now. Perhaps if you could collect an absolute pathname
example of the entire path, it would be easier to figure
out.

And the above article has information on unleashing the
32767 limit instead. But that could have side effects.
On the plus side, you're (less) likely to run into length
issues (no tagged MP3 would have a name that long). On
the minus side, if you run Robocopy with the wrong options
(didn't include the defense against reparse points), then
when Robocopy goes nuts in response, the destination disk
*will* end up with a ~32767 character deep path. Whereas
currently, with the 256 based limitation, you're less
likely to have a huge mess. You can clean up
a 256 character path (say 32 level deep directory structure
with 8 characters per directory name) by hand. If a
path with a depth of 32767 characters were to be created
by an unfortunate mistake, you could need some serious
software to deal with it. You would need to hire
click-monkeys to get to the bottom of the directory
tree :-)

Paul

On Mon, 13 Nov 2017 16:49:37 +1100, "Peter Jason" posted:

I have a 4TB HDD (Seagate) external to the main computer connected to
a PCI slot via a USB3.

Recently my computer crashed and was restored from backup.

Now I'm getting...

"The Recycle Bin on P:\ is corrupted. Do you want to empty the Recycle
Bin for this drive?"

Why you don't simply say "Yes" ???

The other way:
As admin:
Cmd
rd /s /q C:\$Recycle.bin
repeat with all drives in use
restart the computer