AUTOMATIC1111
Add correction file filename length limits on *nix systems
TLDR: Linux sometimes limits filename length, long prompts break, this fixes that.
The issue: on Linux (and other *nix systems) it's possible for filename length limits to exist that apply to some directories and not others. No I cannot explain why, that seems pretty stupid, but for some reason that's actually a thing. It's triggered by LUKS among other tools.
SD image gens with eg [prompt_words] or [model_name] can exceed this limit with sufficiently long prompts and/or model names.
The result is images fail to save or display in the WebUI if a prompt is too long.
The solutions to this are either (A) implement a user-configurable setting for max file length, or (B) just detect it and cap it.
The setting is redundant for the majority of users, and has a predictable value for the remaining few, so probably not wanted.
The way to detect this is via os.statvfs, which in python dev's infinite wisdom not only doesn't work but doesn't exist on Windows for some reason, thus the hasattr check - that block never runs on Windows, does run on Linux (and any other applicable OS).
When ran it just quietly caps file name length to the length, minus five characters to leave room for any extension (eg .webp would be 5, .jpg or .png would be 4)
Side effect of this appears to be that when it triggers, the WebUI embeds a link to a tmp file rather than the final output file. It's the full image file, minus the metadata. The output file itself is stored properly with name and all.
I... honestly don't know why that happens, and it's not majorly breaking, but it might be good to correct that issue.
If you want to test replication: use a Linux install, with anything that has random filename length limits - eg Ubuntu 22 and checkmark the 'encrypt home directory' option during install (LUKS home dir encryption is one such provider of random inexplicable filename length limits), and install the webui in the affected directory (eg within your encrypted home directory), then set your Images filename pattern to something like [prompt_spaces] [seed] [sampler] idk whatever else you weant [model_name] and then generate an image with a prompt of aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb (ie make really really long words, so the word count limit doesn't save you)
Without this fix, it will fail to save the image and fail to load the image in the UI. With this fix, it will save and load as expected.
wouldn't that make more sense inside _atomically_save_image, where you also have an extension and don't have to do +5 (.jpeg/webp?), and after third party scripts had its way with the filename?
... Good thing you questioned that! I realize I mistakenly committed a version that I moved to a different location than where I had it initially as a test to fix the issue of the WebUI loading images like /file=/tmp/tmptdkxjjzb.png instead of via the final output image path.
If it was inside _atomically_save_image, that would prevent the name trimming from being seen by the save_txt code (meaning if save text is enabled, that txt file would run into the same issue of failing to save due to filename length) -- and also the final return at the end, which is an even bigger issue (see below).
I've moved it to directly before _atomically_save_image is called, which I've verified in testing to work as intended. I've also used len(extension) instead of a constant as you suggested (though that alone would risk breaking if somebody in the future uses a two-letter extension, or an empty extension, so actually max(4, len(extension)) to be safe (note that 4 is the length of .jpg and .txt which are used by save_txt and export_for_4chan))
I've also realized the reason tmp files were loading was because I was only updating one variable at a time instead of all of them, so I've now made sure all variables are updated (fullfn and params.filename, ie the two variables that get passed externally). With that fixed, the correct image URL is loaded by the WebUI, works exactly as intended.
I believe as of now every potential issue is accounted for properly.