getsize() fails with very long filenames

[Andrew Ziem]

Reported by bsodx2 http://bleachbit.sourceforge.net/comment/1525#comment-1525

With winapp2.ini enabled Store* gives this error.
"Traceback (most recent call last):
File "bleachbit\Worker.pyo", line 82, in execute
File "bleachbit\Command.pyo", line 74, in execute
File "bleachbit\FileUtilities.pyo", line 347, in getsize
error: (3, 'FindFirstFileW', 'The system cannot find the path specified.')"

Does is have something to do with those entries having characters like these? ∺ ∯

[Andrew Ziem (ahziem1)]

Reproduced the error on Windows 8 with this filename
C:\Users\z\AppData\Local\Packages\WinStore_cw5n1h2txyewy\AC\Microsoft\Windows Store\Cache\0\0-Namespace-https???services.apps.microsoft.com?browse?6.2.9200-1?615?en-US?c?US?Namespace?pc?00000000-0000-0000-0000-000000000000?00000000-0000-0000-0000-000000000000.dat

It is 264 characters long, which is slightly longer than MAX_PATH, which is defined as 260 characters.

[Andrew Ziem (ahziem1)]

Reproduced on Windows 7 with filename about 300 characters long with no special characters

[Andrew Ziem (ahziem1)]

Someone else has this problem with Russian filenames
http://bleachbit.sourceforge.net/comment/994#comment-994

[Andrew Ziem (ahziem1)]

Possible fix committed in 8a5cdd4. Needs more testing.

[Andrew Ziem (ahziem1)]

This link contains the installers for testing the fix
https://sourceforge.net/projects/bleachbit/files/bleachbit/1.7.5alpha/

Testing notes
* Previewing a file with a long name is enough to trigger a potential error (i.e., deleting is not necessary).
* Test on paths with drive letters like C:\file.txt and also on UNC paths like \\server\folder\file.txt
* Test on files with Unicode (i.e., non-ASCII) characters
* One way to create a file with a long name is to open the %TEMP% folder and make a file with a name that is about 220 characters long. Combined with the expanded %TEMP%, the whole path will be longer than 255 characters, which fails in BleachBit 1.7.4 and earYou can test the fix here
https://sourceforge.net/projects/bleachbit/files/bleachbit/1.7.5alpha/

Here is a string that is 200 characters long
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

250 characters
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

[bsodx2 (bsodx2)]

Long files being cleaned seem to be fixed in 1.7.5alpha. Tested with By previewing then cleaning [Store*]. 1.7.4alpha threw an error, 1.7.5alpha cleaned without any errors.

[Andrew Ziem (ahziem1)]

bsodx2: Good news. Thank you for testing.

[bsodx2 (bsodx2)]

maybe a fluke. Long files elsewhere get cleaned fine but after a second cleaning of [Store*] It throws:

[Errno 2] No such file or directory: u'C:\\Users\\username\\AppData\\Local\\Packages\\winstore_cw5n1h2txyewy\\LocalState\\Cache\\0\\0-SimilarApps-https\u223a\u222f\u222fnext-services.apps.microsoft.com\u222fsearch\u222f6.3.9600-0\u222f788\u222fen-US_en-US\u222fc\u222fUS\u222fcp\u222f10005001\u222fSimilarApps\u222fApp\u222f924bba3a-888f-4cd6-91bc-a1510fbb9344\u222fpc\u222f0\u222fpt\u222fx64\u222faf\u222f0\u222flf\u222f1.dat'

previewing shows the characters, cleaning outputs the character code instead

[Andrew Ziem (ahziem1)]

bsodx2: That file matches this pattern
FileKey13=%LocalAppData%\Packages\WinStore_*\LocalState\Cache|*.*|RECURSE

On Windows 10 I installed some apps from the Store and cleaned all the Windows Store (from Winapp2.ini), but I could not reproduce this error. Are you still having anything like this?

The same error ("no such file") also happen as a race condition if another process (like an running app in Windows Store) deleted the file just before BleachBit could.

[bsodx2 (bsodx2)]

sorry for the delayed response, No I am not getting that error anymore with 1.7.6alpha

[Andrew Ziem (ahziem1)]

More fixes committed for long and Unicode filenames ready for 1.7.7