Crash while using file search

[angrierhorse]

• KOReader version: 2019-09 ice cream
• Device: kobo mini

Issue

Koreader crashes to the beautiful new crash screen when I try to search for a file.
I presume this is something corrupted on my kobo as this bug does not affect my other kobo (H2O 2nd Ed.) Any clues on what it might be?

Things I have tried

Clearing book cache
Clearing history cache
Restarting the kobo

Steps to reproduce

1. Open up file search from file browser screen
2. enter search term
3. Press enter

crash.log (if applicable)

09/08/19-13:23:37 INFO  Kobo suspend: woke up!
09/08/19-13:23:37 INFO  Kobo resume: clean up after wakeup
09/08/19-13:23:37 INFO  Kobo resume: unflagged kernel subsystems for resume, ret: true
./luajit: frontend/apps/filemanager/filemanagerfilesearcher.lua:41: attempt to index local 'attributes' (a nil value)
stack traceback:
	frontend/apps/filemanager/filemanagerfilesearcher.lua:41: in function 'readDir'
	frontend/apps/filemanager/filemanagerfilesearcher.lua:89: in function 'close'
	frontend/apps/filemanager/filemanagerfilesearcher.lua:150: in function 'callback'
	frontend/ui/widget/button.lua:224: in function 'action'
	frontend/ui/uimanager.lua:746: in function '_checkTasks'
	frontend/ui/uimanager.lua:1029: in function 'handleInput'
	frontend/ui/uimanager.lua:1115: in function 'run'
	./reader.lua:260: in main chunk
	[C]: at 0x000140c1
!!!!
Uh oh, something went awry... (Crash n°1: 09/08/19 @ 13:25:47)
Attempting to restart KOReader . . .
!!!!

[angrierhorse]

Apologies, this was a false alarm.

I just ran fsck.fat and found/fixed a bunch if corrupted files in /kobo-images.

Problem solved!

[Frenzie]

I think it'd be best not to crash in any case. ;-)

Also you could've deleted the file while the search was running or something.

koreader/frontend/apps/filemanager/filemanagerfilesearcher.lua

Line 41 in 07116b9

if attributes.mode == "directory" and f ~= "." and f~=".." then

[angrierhorse]

As the kobo is no longer crashing the only other info I can provide is some of the fsck output so you can get the gist of what was making it vomit.

root@m6600:~# fsck.fat -a /dev/sdd 
fsck.fat 4.1 (2017-01-24)
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
 Automatically removing dirty bit.
Unfinished long file name "좵⺅⑮蹆䅕:Df9꩜䷷꩟德엪힤濮".
  (Start may have been overwritten by nl|?wb4Ö.^s)
  Not auto-correcting this.
/.kobo-images/∩ß≤?wß┘K.Æ:∩
  Bad short file name (∩ß≤?wß┘K.Æ:∩).
  Auto-renaming it.
  Renamed to FSCK0000.000
/.kobo-images/Å¥!╡╘««.º╙╓
  Bad short file name (Å¥!╡╘««.º╙╓).
  Auto-renaming it.
  Renamed to FSCK0000.001
/.kobo-images/e╒│Zt[┼π.Φ╩-
  Bad short file name (e╒│Zt[┼π.Φ╩-).
  Auto-renaming it.
  Renamed to FSCK0000.002
/.kobo-images/φD═'┬á│D.Q-m
  Bad short file name (φD═'┬á│D.Q-m).
  Auto-renaming it.
  Renamed to FSCK0000.003
/.kobo-images/≤,aèßε.xî╜
  Bad short file name (≤,aèßε.xî╜).
  Auto-renaming it.
  Renamed to FSCK0000.004
/.kobo-images/■╒ƒk_ü.┐│/
  Bad short file name (■╒ƒk_ü.┐│/).
  Auto-renaming it.
  Renamed to FSCK0000.007
/.kobo-images/[╟ñj÷æ▀.╣I╝
  Bad short file name ([╟ñj÷æ▀.╣I╝).
  Auto-renaming it.
  Renamed to FSCK0000.008
/.kobo-images/8 £W≥3ºä.oë
  Bad short file name (8 £W≥3ºä.oë).
  Auto-renaming it.
  Renamed to FSCK0000.009
/.kobo-images/[p╣°?≡½─.ê╪╬
  Bad short file name ([p╣°?≡½─.ê╪╬).
  Auto-renaming it.
  Renamed to FSCK0000.011
/.kobo-images/muFNåôóô.╫òº
  Bad short file name (muFNåôóô.╫òº).
  Auto-renaming it.
  Renamed to FSCK0000.012
/.kobo-images/p1û>PsÉ.H`└
  Bad short file name (p1û>PsÉ.H`└).
  Auto-renaming it.
  Renamed to FSCK0000.014
/.kobo-images
  "." is missing. Can't fix this yet.
/.kobo-images
  ".." is missing. Can't fix this yet.

Performing changes.
/dev/sdd: 4544 files, 251148/344542 clusters

[Frenzie]

If we change line 40 to local attributes = lfs.attributes(fullpath) or {} it wouldn't crash anyway. Any idea how you got those errors?

[angrierhorse]

As the file system dirty bit was set probably an unclean unmount although I am usually very careful about properly un/mount my kobos. In conclusion, I don't really know.

[NiLuJe]

As another data point, nothing but nickel itself should be writing in there, at least on the device's side.

When mounted on a computer, Calibre will, too.

[NiLuJe]

There have been some rather weird developments within the Linux vfat driver lately. It did cause problems with Kindles until Calibre worked around it, but I haven't head anything about Kobos...

[angrierhorse]

I should state I use calibre for library management. I am using Debian 10 (buster)
Linux m6600 4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15) x86_64 GNU/Linux

[NiLuJe]

Okay, so, no vfat shenanigans, those are much, much newer (oh, Debian...) ;).