Total Commander

So I frequently have file paths longer than 255 characters in length from deeply nested folders. Of course even with the latest Microsoft OS, windows 8, Explorer is still limited to dealing with 255 character paths or shorter.

I have to use Totalcommander to copy files to/from these deeply nest folders or copying them all.

But, when I go to delete a file or folder that is deeply nested, Totalcommander does not do it, it refers back to Explorer to do that operation so I cannot do it.

There may be other operations that I am forgetting that Totalcommander refers back to Explorer.exe with. Perhaps renaming or creating a newfolder as well. Please provide full support for long file paths since NTFS can handle thousand of characters in length.

I doubt Window Blue will be any different.

You can delete files a file or folder that is deeply nested with TC.
Just keep in mind, that simple deleting with Del key will just move it to recycle bin (which is a restricted windows component).

You can overcome this by deleting with SHIFT+Del (or SHIFT-F8 if you like).
This will delete directly without usage of recycle bin.

That was the trick.

I went to the directory structure I was having problems with. Explorer said the path was too long and it couldn't be moved to the recycle bin, it had to be deleted. But of course it wouldn't do that, I could only skip the files.
Doing that in Totalcommander (just F_eight), same exact result since it gave the task to Explorer.

However doing shift-Delete in Total commander and then Total commander deleted the files itself successfully.

I re-created the deeply nested section in a similar way and put a file in there, and told Total Commander to F_eight it, it went to explorer, said it had to be deleted instead of recycled, but this time it did it successfully.

So it seems like perhaps the complexity of the long file path file/folder structure overloaded explorer in some unexpected way. That may be why Explorer says it needs to be deleted rather than recycled, yet still errored.
Other times, it can successfully delete the file path

And other times with long file paths, it can be recycled without a problem (I think that's because the relative file path going into the recycle bin is less than 255 characters in length).
So bottom line, Explorer is unpredictable.

But alas, Totalcommander takes care of business. It seems to have full support for copying, renaming, creating folders and deleting within deeply nested directory structures.

Now if only I can get Microsoft to do this, and to stop lying about GB/GiB, MB/MiB notation (for instance a 1000GB drive is 931GB, leading to confusion for newbies that they were cheated in their purchase, because Microsoft should have put in GiB units there ->931GiB).

There were no prefixes like GiB/MiB/KiB at good old times, there were only GB/MB/KB that were 1024-based ones. I don't like theese new GiBs so I would prefer to see GB instead since I don't see any necessity in specifying sizes in 1000-based units.

Yes but Windows lies. It says "GB" next to the capacity of the drive even though it is displaying the GiB, so they should match the number with the correct unit, whether it be one way or the other.

In my Explorer I see size of C: volume as 195 GB and this number is in standard 1024-based units (in drive properties I see 209 609 289 728 Bytes), and all Windows versions use these units since the first one.

Good article about this subject;
techrepublic dot com/blog/window-on-windows/learn-why-250gb-is-not-ever-reported-as-250gb/1511

So that volume of yours is 195GiB , or 209.4GB in size.
Yes the number is in 1024 based units (2 to the power of.) but that notation should be GiB.
Hard disk manufactures say that their drive is say 1000GB and they aren't lying. But that is equivalent to 931GiB, which in windows shows as 931GB, which is bogus.

I don't like modern GiBs, they are uncommon and all GB I treat as 1024-based. The only places where GBs are always used as 1000-based are on HDD (1000GB) and DVD (4.7GB) labels, and I don't understand why (the only reason I can think is fooling).

MVV wrote:I don't like modern GiBs, they are uncommon and all GB I treat as 1024-based. The only places where GBs are always used as 1000-based are on HDD (1000GB) and DVD (4.7GB) labels, and I don't understand why (the only reason I can think is fooling).

It's not a matter of likening, if G M K are well know standard 10 base prefixes, you shouldn't mix it with 2 base prefixes. Otherwise confusion arises. One good example is the use of Billion: For US is 10^9 and for Spain and latin is 10^12. A mars rover was lost because these kind of units mixture.

Yes but in IT for years and decades G M K were 2-base prefixes so it is a bad idea to change their meaning just because someone doesn't know about this fact.

One good example is the use of Billion: For US is 10^9 and for Spain and latin is 10^12.

You're right, it is good example. But if most IT people know that G is 2-base prefix new 10-base prefixes will confuse them.

I'm not the biggest fan of "i" units myself. I don't mind reading them, I might even be persuaded one day to write them (in short form), but if I ever (this sentence being the obvious exception :) write or pronounce kibibyte, mebibyte and such, then let my hand or tongue fall off. :)

But the problem does exist. It's not only "IT people" now, almost everyone comes to touch with computers. And the same unit meaning 1000 or 1024, depending on where it's used, is not good. As 10-base units are more common everywhere else, new 2-base units are sort of good idea. Even though it's far from perfect, because even though "100 MiB" is clear, "100 MB" still might mean both. So it's a "fifty years from now" solution (hundered with current adoption rate), but better than nothing I guess.