Calc will not save files on a Windows 10 machine

I have a friend who recently bought a new laptop with Windows-10
preinstalled. At my suggestion, she installed the LibraOffice suite
(portable version, from Portable Apps.)

The first time she tried to update an old .xls file from Microsoft Office
2000, she was able to do so with no problems. But the program immediately
pops up an error box when she tries to save the updated file. The error
message is

Error Saving the document <doc name>
General Error
General Input/Output Error

The header bar in the error pop-up confirms that the error is being
generated by LibraOffice, and not by Windows 10.

On further investigation, it turns out that the program won't save newly
created Calc files created by the program itself. Have tried "Save". "Save
As", "Save a Copy". In every case, the same error pop-up is immediately
displayed. So, for example with Save As, you don't get an opportunity to
change the file name, extension, or destination.

Some other interesting observations:

I downloaded the very latest version of the program 5.1.3.2. No impact on
the problem.

The Writer module works just fine. I can modify and save old .doc files, and
newly created files are handled with no problems, regardless of what format
I choose to save them in.

I have LibraOffice installed on my own Windows-7 machine and have never had
any problems with it. And I routinely work with old Microsoft Office files,
both .doc and .xls formats, with no issues at all.

Unless someone can tell me that this is a known bug in LibraOffice, I am at
a complete loss in resolving this problem. Ideas?

Can you test the same version and same file, in your Windows 7 machine?

Windows is prone to introduce incompatibilites ex-professo.

Thanks for your interest. I don't have hands-on access to the Windows 10
machine at the moment. I could probably get a copy of the file that
originally had the problem.

BUT, my last experiment was to create an entirely new spreadsheet file (just
a few cells, filled with arbitrary integers) on the Windows 10 machine, and
the Calc program wouldn't save that, regardless of whether I tried "Save" or
"Save as". So it seems unlikely the the original file was the source of the
problem. I believe that she has tried several files, with the same result.

One thing I will have to check back on is a few settings changes I made to
set up default file paths, and Windows file type associations so that the
user wouldn't be confused needlessly by a slightly different working
environment.

But, it still seems to me that a newly created file should be saved without
protest. If I made some errors in the configuration changes I made, I might
expect to have a little trouble finding where the file got saved. But I get
the error report pop-up immediately, as soon as I select any of the
available save options from the "File" menu.

Have you tried creating a Calc sheet as Admin?

Several ideas that might help.

A downloaded file receive a "blocked" attribute. I ignore if that propagates to files that the instaler expand and copy.

The second thought I had is that you are using a portable installation, that you can test it on Windows 7.

I remember that some operations require java and for portable programs is preferable portable java. That is true for the assistants (letter, fax, agenda, presentation ...) and for the options on the start up panel "Writer Document", "Calc book", etc for new documents. But the menus (file - new - type of document) works well without needing java.

Also, LibreOffice web page warns about the compatibility of 32/64 bits versions with processors of 64 bits. Is your version compatible?

Windows 10 has also preference to MS software and probably and have been mentioned that alternative software rutinously are having problems with Windows 10.

I got a tip from somebody who reads this forum that his best guess was that
the user profile data had been corrupted. The portable version does not
store the profile data in the same location as the full install version. In
view of that, I downloaded a new copy of the conventional non-portable
version and that immediately solved the problem. Likely the corrupted
profile conjecture was spot on. Thanks to everybody for their inputs.