I've been using libre portable for years. Never an install problem
(either fresh or upgrade installs). Last working install I have is:
4.3.5.2, multilingualStandard, "remove languages" option,
installing to "j:\" (root of a partition)
windows xp, sp3
Today I have tried installing both 4.4.3 and 4.4.2,
both have install errors.
Initially I tried installing 4.4.3 into(onto/upgrade) my 4.3.5.2 directory.
When that didn't work I tried putting 4.4.2 over 4352. Nope.
I then tried installing fresh copies of both 443 and 442 into new/clean directories.
("j:\LibreOfficePortable")
Still errors.
The installer will proceed about halfway then result in error dialog:
"Extract: error writing to file xxx". ("OK" is only option on dialog)
More often than not 'xxx' will be "_0.cfs" (see log).
But I HAVE received the error with a different filename
on at least one attempt (I have tried this about five times).
Sorry...didn't record the filename or log on that time.
After clicking "ok" on error dialog the only possible option
from the installer screen is to then click CANCEL and exit
installer. Any ideas??? Did something about the installer
change recently? (Seeing the error on more than one
distribution and ALSO seeing it happen on more than
one specific file would suggest the problem is installer
based and not file specific. There also doesn't seem
to be a fixed point when then error will be thrown
during an install. Perhaps this is some sort of timing
conflict or concurrency issue?)
(My hard drive, computer, filesystem, etc are functioning
fine with no hardware problems. No free space problem.
I have also downloaded multiple copies of
both 4.4.3 and 4.4.2 (including from sites other than
portableapps) so this is not a corruption issue.)
==========================
Relevent log below:
-BEGINNING-
Output folder: J:\LibreOfficePortable
Installing LibreOffice Portable...
Create folder: J:\LibreOfficePortable\App
Create folder: J:\LibreOfficePortable\App\libreoffice\share
Extract: LibreOfficeBasePortable.exe
Extract: LibreOfficeCalcPortable.exe
Extract: LibreOfficeDrawPortable.exe
.....
Extract: help.key_
Extract: help.tree
Output folder: J:\LibreOfficePortable\App\libreoffice\share\extensions\wiki-publisher\help\zh-TW\help.idxl
Extract: _0.cfs
Extract: segments.gen
Extract: segments_3
Output folder: J:\LibreOfficePortable\App\libreoffice\share\extensions\wiki-publisher\help\zu
Extract: help.db_
Extract: help.ht_
Extract: help.jar
Extract: help.key_
Extract: help.tree
Output folder: J:\LibreOfficePortable\App\libreoffice\share\extensions\wiki-publisher\help\zu\help.idxl
Extract: _0.cfs
-END OF LOG-
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on BlueSky
Follow us on Facebook
Follow us on LinkedIn
Follow us on Mastodon
Follow us on Twitter
When an installer shows that error, that means something at the OS or drive letter is not allowing a given file to be written. This can be caused by a path that is too long (when you have multiple sub-directories containing LibreOfficePortable), a drive that is failing and has errors, or an infection or corruption at the OS level. It's nothing wrong with the app or installer itself.
Sometimes, the impossible can become possible, if you're awesome!
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.
That's why I listed the other reasons which are the ones likely to apply in your case and even mentioned them in the subject of my post while not mentioning path length in the subject. I'm unsure why you ignored those other reasons. Though path length could apply here too if you somehow managed to set the max path length too short at the os level (you'd have to set it pretty short though).
Sometimes, the impossible can become possible, if you're awesome!
obviously not a full solution but does a plain english install work?
Wm
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.
There are no other users with issues in the current release. Most previous issues are due to path length on older OSes. Windows XP has a short path length and LibreOffice Portable and OpenOffice Portable installs would generally fail to anything besides X:\LibreOfficePortable or X:\PortableApps\LibreOffice. Most issues you see in the forums are older ones with issues installing to Documents or Desktop, which on Windows XP are actually quite long with C:\Documents and Settings\LoggedInUsername\Documents\PortableApps\LibreOffice.
Your issue is separate and due to an issue specifically on this machine or drive. I'd suggest installing it temporarily to C:\LibreOfficePortable and see if the install and running of the app work as expected. Additionally, you should absolutely scan drive J for errors.
Remember, installers are mostly dumb. If they can't write a file, it's not because there's an error in the code. The installer is just extracting a file and then trying to write it to where it was told to. If it fails with an error on a write, it's either an issue with the hardware, a permissions issue on NTFS, a corrupted file system, etc. In this case, the code that is causing that file to be written out hasn't changed in over 3 years.
Sometimes, the impossible can become possible, if you're awesome!
(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.
That sort of error with the TEMP files failing would be an issue within the NSIS installer code itself. It's used for all kinds of installers like the regular Firefox local installer. Our portable installer code sits atop it. I guess they don't check for a full drive on the TEMP directory. Though, if your system drive is full, your PC would be barely functional.
I might be able to throw a check into the installer on start ensuring there's at least enough space within TEMP for the full app and throw an error if not. I can't throw errors on the file writes without editing NSIS' C code.
Sometimes, the impossible can become possible, if you're awesome!
Out of space type stuff is some of the oldest in the book.
It certainly didn't trigger in my head based on what I
was seeing. (Like asking somebody to check "is the
computer plugged in" at the start of a support call
I don't think any concern or change is needed.
I have certain sandboxing and restrictions set up
to limit (shared) resources on a box so that's why
it happened to me. The machine isn't unusable
I just have a certain config.
Overall...granted...if a zillion people are using this installer
and it is old school then you would have thought that
at SOME point in the past a person would have coded
in a space check. But like I said it is what it is.
Cheers