A process generated (as requested) a 3.7 gigabyte zip file last night. For the size it worked pretty well. I did notice something funny though; there seems to be no way to display its size correctly, other than downloading it to my local system.
The filesize-in-bytes (~3.7 billion) is well past the integer overflow point (~2 billion). When I view the file's properties directly in designer, it shows a *negative* filesize:When I click into the document properties, I see the same thing.
When calling the "document" function on the file directly, I see a corresponding negative integer (i assume this somehow corresponds to the integer overflow, but I can never keep it straight in my head) --
In this case it's not critical. However I can imagine future use cases where not being able to internally pull an accurate file size could be a big deal. Has anyone developed any neat tricks and/or workarounds for this? ( I mean other than the obvious, "why on earth are you allowing Appian to generate a zip file over 3 gigabytes", which is a good question for a different conversation ;-) )
Discussion posts and replies are publicly visible
Why on earth ARE you generating a 3GB Zip File?
Why are you generating a file at all (i.e. why not bring users to the data rather than data to the users)?
Stewart Burchell said:i.e. why not bring users to the data
Come on, you should already know that the venn diagram between "reasonable/logical solutions" and "stakeholder requirements" only has the thinnest sliver of overlap ;-)
In this case there's a recently-new requirement to (on demand, but not in real-time) take a total export comprising all system-resident files of a certain subset of system-side "types" (i.e. different certs, etc), for a group of just over 1,000 users, per contractual details. The implementation wasn't really up for discussion beyond a certain point. I (at least) enforced the idea that it would run only at 2 AM and can only be run up to once per day.