Adammy661 Posted June 28 Share Posted June 28 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 Link to comment Share on other sites More sharing options...
redwolfe_98 Posted June 28 Share Posted June 28 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. Link to comment Share on other sites More sharing options...
JamesRM Posted June 29 Share Posted June 29 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 Link to comment Share on other sites More sharing options...
Adammy661 Posted June 29 Author Share Posted June 29 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 Link to comment Share on other sites More sharing options...
JamesRM Posted June 29 Share Posted June 29 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. Link to comment Share on other sites More sharing options...
Adammy661 Posted June 30 Author Share Posted June 30 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 Link to comment Share on other sites More sharing options...
JamesRM Posted June 30 Share Posted June 30 3 hours ago, Adammy661 said: Sorry to disturb you again by quoting. No problem at all, I'm glad it helped Link to comment Share on other sites More sharing options...
Moderators Andavari Posted July 2 Moderators Share Posted July 2 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. Link to comment Share on other sites More sharing options...
JamesRM Posted July 2 Share Posted July 2 (edited) 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 Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now