Images not displayed in report if source path gets to long

[viper3400]

Hi @jan-molak

When it goes, it goes. Found another one, which is not a bug at all, but a kind of limitation, which I like to address to the community in case others having the same issue:

While verifying fix for #634 I wondered why there are still images not displayed in my report. Being as descriptive as they are, the PNG file names of the created screenshots could become very long.

Given a deep folder structure and the fact, that I'll open the index.html of report directly from Windows Explorer, the src attribute of the images point to a file:// source, which will easily exceed the browsers URL limitations (maybe around the 256 characters limit, did not figure this out completely).

One won't be able to open this image in the browser directly when passing the URL into the address bar, as well

As workaround, I just copied my report into c:/tmp and the images could be displayed.

(Don't know if this issue only applies to Windows.)

Maybe file names could be shortened in future, but that won't solve the problem in some edge cases at all.

[jan-molak]

Hey @viper3400 thanks for reporting this issue; I'd like to dive into it a bit deeper.

I believe that a browser URL can have up to 2000 characters, so I don't think we're hitting that limit.

What we might be hitting, however, are limits of the Windows OS where it seems like the total length of a file system path cannot exceed 260 characters. My original understanding was that the file name needs to be shorter than ~250, but it looks like this limit applies to the entire path.

I think there are two options for the ArtifactArchiver here:

• it could be made configurable to enable or disable the human-friendly segment of the artifact name altogether
• alternatively, it could calculate the length of the path it would like to store an artifact at, and truncate the human-friendly segment as much as needed to meet the limit of being under 260 chars

The third option I guess would be for people using WIndows to enable long paths, but that's a bit hairy.

Thoughts?

[viper3400]

Hi @jan-molak

Actually, on the OS I found this issue (Windows Version 1903) the long paths are already enabled:

So I think, there must be another reason for this. As well, not every user may have access to the Windows registry (maybe in a restricted business environment, where in addition registry settings could be overwritten by group policies at any time.)

Given, that the reason for this is not quite clear, I think it will be difficult to calculate the limit. As well this option will fail, if the report will be copied to another location, where the limits will not be the same.

So I would suggest the option of disabling the human-friendly segment by configuration, which seems the simplest solution at all ( I don't know, if the report generation makes any other usage of the name to generate descriptions or so, but I suppose all data is taken from the JSONs.)

Thanks for your support.
Regards, Jan.

[viper3400]

Hi @jan-molak

I've done some enhanced testing with this and this seems not to be as simple. I've enabled long paths. But, as written at the bottom of the Microsoft article just some of the Windows APIs support long paths. So, I haven't been able to create a folder/file structure in Windows Explorer longer than 247 chars at all. You can copy & paste files in deeper structures, though. But then you can't change long file names any more at this depth. Seems fuzzy.

I've seen, you've already a file name limit in place here:

serenity-js/packages/core/src/stage/crew/artifact-archiver/ArtifactArchiver.ts

Line 81 in 3507e04

return Path.fromSanitisedString(

So still advocating for a further file name limitation.

[jan-molak]

Hey @viper3400 and thanks for such thorough research! I think 2.19.10 should address the issue you're seeing as the file name will now never exceed ~90 characters.

Thanks for your help and let me know if you spot any other issues!

Jan

Note to self: ArtifactArchiver will need some further changes to enable #571