Install Failure "Extract: error writing to file _0.cfs"

Um...ok...but....
"LibreOfficePortable" is the default directory installation name and putting that directory at the root of a partition ("j:\") is logically the shortest possible install path(s) I could create. So I've done what any default user would do.

If the default directory makes the path too long then it would seem to conclude that
the installer needs to:
1) default to something shorter like "LOP";
2) use subdirectories that are shorter also:
"..Output folder: J:\LOP\App\LO\share\extensions\wiki.."
(Using the last folder name from log file above and replacing
to make LOP and LO instead of the longer names).

In this case I have control over "LibreOfficePortable" which is the default and can change it (and will see if that fixed the problem) but I don't have control over the subfolder names being used by the portable construction. And even if those don't error out when I shorten the default install directory...perhaps they will again in the future (or if moved after install to a deeper location??) so making them as short as possible might be best.

?

NOTE: that I did read the "Known issue below" before making this bug post. The known issue:
A) references running and not installation; Had it said installation errors (perhaps with example) I might have been better informed;
B) mentions that librePortable should work fine from a root partition location, which is what I had done. So again it didn't trigger recognition that this was an issue. (Note that I suspect the Libre installation has increased in path size and complexity over time and that these install/run errors didn't exist a while ago with older versions. There are creeping up on us as the program expands.)
======KNOWN ISSUES======
Long Paths and Odd Characters - LibreOffice doesn't like running from overly long paths. So, while it will work directly from your desktop... if you have it within a subdirectoy on your desktop, it will probably fail claiming that some files are corrupted. LibreOffice also doesn't like certain characters like dollar signs in the path. This is why it's best to have the LibreOfficePortable directory in the root of your drive, or within a PortableApps directory in the root of your drive. The launcher attempts to check this for you and will let you know.

Can you define what you mean by a "Plain english install"?
Don't remove languages?
Use NON-portable Libre instead?
???

I just proceeded to try installing LibreOfficePortablePrevious_4.3.7_MultilingualStandard.paf.exe to "J:\" (root of partition). I overrode LibreOfficePortable and directed it to "Libre" ("J:\Libre\..."). (In order to try and make the full path almost as small as possible. Next I guess I just use the single letter "L")

Result: install error (log tail below).
As far as path length or such I'm not even aware of what sort of setting you are implying is on my computer or I have set. Every other windows install for the last ten years or so has no problem with paths and subdirectories and such. I'm really confused why libre (or portable) does. I don't have some sort of weird config. Since I'm installing to root how else can I solve this?

And...the output folder causing the error (this time) is:
"j:\libre\App\libreoffice\share\extensions\dict-en"
This is hardly some earth shattering length beyond usability.
And an installation program is only COPYING files into a location,
we aren't even running anything. So how can this problem be with
Libre program itself? The installer can't simply copy files into a
directory 6 or so deep??
.....
Output folder: j:\libre\App\libreoffice\share\extensions\dict-de\META-INF
Extract: manifest.xml
Output folder: j:\libre\App\libreoffice\share\extensions\dict-en
Extract: Lightproof.components
Extract: Lightproof.py
Extract: Linguistic.xcu
Extract: README.txt
Extract: README_en_AU.txt
Extract: README_en_CA.txt
Extract: README_en_GB.txt
Extract: README_en_GB_thes.txt
Extract: README_en_US.txt
Extract: README_en_ZA.txt
Extract: README_hyph_en_GB.txt
Extract: README_hyph_en_US.txt
Extract: README_lightproof_en.txt
Extract: WordNet_license.txt
Extract: affDescription.txt
Extract: description.xml
Extract: dictionaries.xcu
Extract: en_AU.aff
Extract: en_AU.dic
Extract: en_CA.aff
Extract: en_CA.dic
(ERROR ON THIS LAST FILE).

Can I return to a common troubleshooting view and ask
"what changed" with the installer?
Libreportable has worked for me on these same (multiple XPsp3)
computers for years and years. Now the installer won't work yet
nothing about my multiple machines would seem to warrant the
change. I assert again it's an installer issue (and since the program isn't
even running). Is there other logic that would argue differently?

SOME sort of issue has been clearly reported by multiple users.
I doubt they have all changed "path length" or some other such variable.
(or that they are putting the program in a location different from where
they put it half a dozen times before).

Could it be that the presumed diagnosis at this time is not
correct and that there is indeed a subtile regression bug somewhere
in the installer? Only asking. We've all been there where we
thought it was X then finally realized Y. Maybe that's my position
and I'm the one wrong or causing this. I just don't see what
I've done differently however.

The fact that this error occurs on DIFFERENT files in different locations
seemingly randomly during install seems to point to some sort of
timing or race condition or such during install. Just my view.
If the error was always the same file with SAME path I could believe
different.

Open to thoughts.

(Certainly understand about the "documents" (or "my documents") location.
Those are horrible disasters forced upon us by microsoft ages ago. Ugh.)

Ok..got it....
Your comment about the installer not changing in 3 years gave
me a start. I had a hunch and found the problem.
It was a common out-of-disk/memory error.

Even though the installer log says "extracting..." (file by file)
and can visibly be seen placing each of those files
into the install location one by one (by watching during
install progress)...the installer is also creating a multi
hundred meg tmp file in the OS environment (different location).

This topped out the amount I had allotted (I've got some
sandboxing going on) and the installer
would end without me understanding where it went wrong
(when it couldn't expand that tmp file past about 300meg.)

Upon exiting the installer, the large tmp is wiped so none of my
other programs would run into the issue and I wouldn't see it
on any stats.

And the reason the installer would error out at random file names
would be because the tmp space size would change
slightly over time moving the error location.

A fix (for clearly a rare situation) would be for the installer
to monitor the error code returned when it calls the OS
to expand that tmp file. Failure of call to expand
changes the error dialog to "out of space"
instead of 'error extracting file xxx.xxx'.

But it is what it is and we all probably have more important things
to do, (but if the installer is ever tweaked for some other reason
it wouldn't hurt).

Thanks for the help. For what it is worth I've donated 4 times
to the project so certainly appreciate the assistance and value.