[Bug Report] Logging when 500 error occurs

[Leeingnyo]

Describe the bug
In WSL2, with a long filename (really long, its path has more than 200 characters, I think) scan job failed. here is an error log when starting the mango up

Unhandled exception in spawn: Error reading directory entries: '/root/mango/library/some-path-that-has-a-long-filename': I/O error (File::Error)
  from usr/share/crystal/src/crystal/system/unix/dir.cr:24:7 in '???'
  from usr/share/crystal/src/dir.cr:58:19 in 'entries'
  from Mango/src/util/signature.cr:62:7 in 'contents_signature'
  from Mango/src/util/signature.cr:66:25 in 'contents_signature'
  from Mango/src/util/signature.cr:66:25 in 'contents_signature'
  from Mango/src/library/title.cr:91:5 in 'examine'
  from Mango/src/library/library.cr:146:7 in 'scan'
  from Mango/src/library/library.cr:59:17 in '->'
  from usr/share/crystal/src/primitives.cr:255:3 in 'run'
  from ???

It's ok because this is caused by the limitation of Docker

However, a manual scan on an admin page doesn't print any error message.
It just return 500 error, not logging what error occurs.
Can we logging what this is when 500 error occurs?

To Reproduce
Steps to reproduce the behavior:

1. make file that has a long filename (200 characters over)
2. run Mango server (scan would be failed, but that is printed)
3. go to admin page, click scan button
4. loading indicator is disappeared and /api/admin/scan request got 500 status code. no error message in docker log

Expected behavior
Logging when 500 error occurs

Environment (please complete the following information):

• OS: Windows 10 Pro, WSL 2

[hkalexling]

Hey thanks for the report. I was trying to test this but the max filename length on Linux is 255 bytes so I couldn't create the file. Will try this on Windows + WSL.

[Leeingnyo]

Thanks for investigating on this.

For your reference:
Though the max length of a Windows filename (including a path) is 260 bytes, I can only make a file with

123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890.zip

in C:\, which it has 247-length filename including a path (C:\)

Surprisingly, I found that the scan was ok when a filename consists of only ASCII characters.
However, It failed when a long filename has non ascii characters (ex. Hangul)!

I can make the same file length with non ascii characters in Windows like a following one, but this file isn't appeared in the result of ls at WSL2 and the mango scan failed.

가나다라마바사아자차가나다라마바사아자차가나다라마바사아자차가나다라마바사아자차가나다라마바사아자차가나다라마바사아자차가나다라마바사아자차가나다라마바사아자차가나다라마바사아자차가나다라마바사아자차가나다라마바사아자차가나다라마바사아자차가나다라마바사아자차가나다라마바사아자차가나다라마바사아자차가나다라마바사아자차가나다라마바사아자차가나다라마바사아자차가나다라마바사아자차가나다라마바사아자차가나다라마바사아자차가나다라마바사아자차가나다라마바사아자차가나다라마바사아자차.zip

For a sure I say, I didn't mean to resolve this long filename issue.
Why the same scan job doesn't show error log when called by API router, Is it automatically handled without logging?

[hkalexling]

I think it's because when the filename has only ASCII characters, its size in bytes is within the 255 bytes limits imposed by Linux so it works. When you include CJK characters, even when the number of characters is the same, the byte size increases and thus breaks on Linux.

Yeah it looks like we didn't do any error handling for this. Updating this to show an error message on top should be enough. I will work on this.

https://github.com/hkalexling/Mango/blob/dc5edc0c1b218d994cff8fd5111c44adc2282d3c/public/js/admin.js#L29-L36

[mango-assistant]

Hi there! The issue has been fixed in v0.26.0. Thanks for the bug report!