Why is CCleaner so unstable to delete big files with big names? Overwrite not wo

[Adammy661]

Why is CCleaner so unstable to delete big files with big names? Overwrite not working as intended.

WinRAR shows all directories in the computer, including hidden ones that wouldn't appear even with the Hidden Files options activated. With that, i can enter the Recycle Bin folder and see what's there

Generally, CCleaner does a great work, but i'm having trouble to delete video files for some reason. What pisses me off is the fact that they get hidden when CCleaner "cleans" them, thus obsfucating them from the normal Recycle Bin view, but they're there. And they're still working, because i can copy them through WinRAR to some random folder and play the video just fine.

https://imgur.com/a/SVZmxfM

I already tried Overwrite with 1 Step, 3 and 7. All the same s**t, files getting hidden in Recycle Bin. Why is this even a problem to begin with? Why can't the file just go through the process and be deleted? 

Turns out this were always happening with long filenames (or long directories+filesnames). 
I know because i renamed the exact files that weren't going through the overwrite process and guess what, they were deleted just fine

I end up having to delete them through the WinRAR, otherwise it would be some sort of dead file taking up space secretly.

By the way, the other Recycle Bins are from other users. My Recycle Bin is the second one

Makes the option of overwrite virtually useless. If this is going to happen, might as well disable and as alternative, run Wipe Free Space at midnight, which is not what i wanted to do.

It's worth to notice that the empty Recycle Bin size is 129 Bytes, with a single file called Desktop.ini
I know for sure because when i'm not deleting big files, CCleaner cleans correctly and the Recycle Bin is always 129 Bytes.

----------------

As it can be seen from the images (https://imgur.com/a/SVZmxfM), i had 24 GB in the recycle bin. After concluding the CCleaner process, i was left out with 5GB which was the Kono Subarashii files

If i delete them, i'm left out with 129 Bytes, which is Recycle.bin's base state

OBS: Also note that in the beginning i selected all Recycle.bin, including from other users. That doesn't mean anything as all other users have a clean Recycle.bin
I just selected all folders for no special reason
----------------
Why CCleaner allows leftovers to exist is completely beyond me

TL;DR - CCleaner fails to overwrite files with big filenames

[redwolfe_98]

it's possible. sometimes things with super-super-long names don't precess properly, i suppose because that scenario is not taken into account. it might be a bug that the developers of ccleaner need to take into account.

maybe a solution would be to empty the recycle bin in the normal way as opposed to using ccleaner toremove the files, there. or you could try deleting the files in the normal way, if that is an option. i don't use the recycle bin so i am not familiar with it.

it sounds like the files are being deleted but that, with winrar, you are able to recover the deleted files.

[JamesRM]

A couple of things come to mind:

• The free offering of CCleaner will only empty the Recycle Bin of the executing user, unless one pays for Pro and chooses all users in its options that'd be by design.
• Windows has a historically low length limit for paths by default, it is 260 characters for it all (volume letter, colon, separator...); you can forgo that limit by using a group policy or setting its associated value in the Registry[1] so that most apps can work with paths longer than that, see if that helps. Explorer won't allow you to create a path longer than 260 chars even then, Microsoft isn't big on consistency.
• Files and folders whose paths are longer than that can be accessed regardless using the Unicode prefix to the path (prepending the path with "\\?\"), it doesn't get rid of length limits altogether, but they are substantially larger; CCleaner not doing it could be because it's not a priority, so they didn't get to do it yet, or they don't care for it.

19 hours ago, Adammy661 said:

Makes the option of overwrite virtually useless.

I wouldn't say that, it should still work for files with paths that don't exceed 260 characters, but if the program doesn't delete a file (for whatever reason), one can't expect it to overwrite its contents either . In any case, overwriting isn't needed for SSDs, not long after a file is deleted its data is erased internally, 1 pass would be enough for HDDs if privacy were a concern (and you ask me haha), CCleaner mangles the MFT entry (metadata) when secure deletion is chosen already.

 

[1]: The group policy that allows long path access is Computer Configuration → Administrative Templates → System → Filesystem → Enable Win32 long paths, its Registry value is at "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem", a DWORD named LongPathsEnabled, set to 1 when enabled. If you are running a Home version of Windows and don't have access to the group policy editor, you could create that value instead. For example, running this from an elevated command prompt or PowerShell:

reg add HKLM\SYSTEM\CurrentControlSet\Control\FileSystem /v LongPathsEnabled /t REG_DWORD /d 1 /f

[Adammy661]

3 hours ago, JamesRM said:

A couple of things come to mind:

• Windows has a historically low length limit for paths by default, it is 260 characters for it all (volume letter, colon, separator...); you can forgo that limit by using a group policy or setting its associated value in the Registry[1] so that most apps can work with paths longer than that, see if that helps. Explorer won't allow you to create a path longer than 260 chars even then, Microsoft isn't big on consistency.
• Files and folders whose paths are longer than that can be accessed regardless using the Unicode prefix to the path (prepending the path with "\\?\"), it doesn't get rid of length limits altogether, but they are substantially larger; CCleaner not doing it could be because it's not a priority, so they didn't get to do it yet, or they don't care for it.

 

That's all that i needed to know, thanks. I wonder if Linux distros don't have this problem (if people even use CCleaner in Linux, that is. Never used so i don't know) or if it was fixed in Window 11

Indeed, i am using Home version, so i will try out the registry provided. Thanks for the time writing this

[JamesRM]

56 minutes ago, Adammy661 said:

I wonder if Linux distros don't have this problem

More or less! But it isn't as strict, if memory serves there was a limit of 255 bytes for each of the path components and a larger limit for it all (I don't recall how much), so in practice it is less likely to be over the limit. Think of it as having 255 characters for each file or folder name and being able to go many levels deep even when using those 255 chars every time. I don't think I ever reached the limit in Linux, no idea what would happen but I'm curious now .

Windows 11 hasn't changed the way long paths work in Windows likely, although I haven't tried it. The problem is backwards compatibility and accommodating programs that expect paths to be a maximum of 260 characters long (really old software or careless programmers), that's why even though they added the long path group policy at some point in the Windows 10 lifecycle it isn't enabled by default.

In practicality is not that big of a deal, notice how the program that created those files in your case had no problem doing it, but it does lead to situations like the one you saw when a program tries to access a long path and doesn't take its length into consideration, or when one tries to move files around and suddenly the path exceeds those 260 characters. Ideally, CCleaner should handle those situations correctly, or at least notify users about it.

Deletion also works in a similar manner too on Linux, for efficiency. There are different filesystems, but the ones I know of just mark the entry that stores the metadata of a file (name, timestamps, permissions, ...) as unused when the file is deleted, and life goes on. It may be reused for another file later on, and the contents of that file overwritten at some point as well, but not explicitly when the file is deleted. I don't think Linux users use CCleaner, I certainly don't, but there are other programs that do cleaning and secure deletion if one wants to.

[Adammy661]

On 29/06/2024 at 10:27, JamesRM said:

 

reg add HKLM\SYSTEM\CurrentControlSet\Control\FileSystem /v LongPathsEnabled /t REG_DWORD /d 1 /f

Sorry to disturb you again by quoting.

Just came here to say that it actually works, at least for me. I copied the exact same folder with the same files and started the experiment again by deleting it then running CCleaner, then checked WinRAR and there's no leftovers. Even the Kono Subarashii files (which were the ones not getting deleted, as shown in the previous images) were successfully deleted. Recycle Bin 129 bytes as it should

Consider the thread closed. Thanks once again for all of this

[JamesRM]

3 hours ago, Adammy661 said:

Sorry to disturb you again by quoting.

No problem at all, I'm glad it helped

[Andavari]

On 29/06/2024 at 08:27, JamesRM said:

[1]: The group policy that allows long path access is Computer Configuration → Administrative Templates → System → Filesystem → Enable Win32 long paths, its Registry value is at "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem", a DWORD named LongPathsEnabled, set to 1 when enabled. If you are running a Home version of Windows and don't have access to the group policy editor, you could create that value instead. For example, running this from an elevated command prompt or PowerShell:

reg add HKLM\SYSTEM\CurrentControlSet\Control\FileSystem /v LongPathsEnabled /t REG_DWORD /d 1 /f

Registry scripts (or .REG files) for tweaking things aren't usually posted on here for obvious reasons. If suggesting someone could import some settings at the very least have a way to undo it just as easily.

[JamesRM]

1 hour ago, Andavari said:

Registry scripts (or .REG files) for tweaking things aren't usually posted on here for obvious reasons. If suggesting someone could import some settings at the very least have a way to undo it just as easily.

Oh! That was no script, just a command to set value I described in the paragraph.

For completion, reverting to Windows' default can be done by setting the value to 0 or deleting it altogether. For example, executing this:

reg add HKLM\SYSTEM\CurrentControlSet\Control\FileSystem /v LongPathsEnabled /t REG_DWORD /d 0 /f

Breakdown:

• "reg" → the tool to run.
• "add" → indicates we want to add a new subkey or entry.
• "HKLM\SYSTEM\CurrentControlSet\Control\FileSystem" → key to be added, in this case because what we're adding is a value, key where the value will be.
• "/v" → indicates a value (entry) is to be added or edited.
• "LongPathsEnabled" → name of the value.
• "/t" → indicates the type follows next, necessary if we are creating it since there are several options.
• "REG_DWORD" → this is the type for that value, a DWORD.
• "/d" → indicates the next argument is the actual value, the data to use.
• "0" → the number 0, to disable long paths in this case, it was 1 earlier.
• "/f" → option not to ask for confirmation, not mandatory at all, if not used and the entry existed already reg would ask for confirmation instead.

Or this (or through RegEdit, etc.):

reg delete HKLM\SYSTEM\CurrentControlSet\Control\FileSystem /v LongPathsEnabled /f

• "delete" → indicates we want to delete a subkey or entry.
• the rest of the arguments were detailed above.

Description of the policy, for those who don't have access to the group policy editor, it is also detailed in the group policy settings reference spreadsheet for the Windows version one's running:

Quote

Enabling Win32 long paths will allow manifested win32 applications and Windows Store applications to access paths beyond the normal 260 character limit.  Enabling this setting will cause the long paths to be accessible within the process.

Edited July 2 by JamesRM