Moving to common as it apparently hit many filters on windows.

Confirming the issue.

Isn't this a duplicate of bug 210098?

Yes, it's the same bug. But I'm not sure which way we should close as duplicate, since I think it's up to us, the Calligra developers, to fix this issue...

Created attachment 69201 [details]
.docx Debug

debug info - opening .docx file.

Created attachment 69202 [details]
.doc debug

debug info - opening .doc file.

KZip uses KSaveFile, and in KSaveFile::finalize(), the KDE::rename call uses WINAPI's MoveFileExW, which returns zero (failure) and GetLastError gives error "5: Access Denied" and I have no clue why.

In KSaveFile I have at that point:

d->tempFileName:  "c:/users/andrius/appdata/roaming/.kde/tmp-andrius-pc/wordsvc6680.tmpgx6680.new"
d->realFileName:  "c:/users/andrius/appdata/roaming/.kde/tmp-andrius-pc/wordsvc6680.tmp"

As far as I could see, [wordsvc6680.tmpgx6680.new] was a valid ODF file, but since KSaveFile fails, no data is written to [wordsvc6680.tmp].

I've tried using QDir::toNativeSeparators, but this does not seem to be the problem there, as KSaveFile is also used for configuration files (e.g.: c:/users/andrius/appdata/roaming/.kde/config/wordsrc) and works normally.

do the tmp-andrius-pc exist
and if not does it work if you create that directory by hand

(In reply to comment #8)
> do the tmp-andrius-pc exist
> and if not does it work if you create that directory by hand

As I said, the file in KSaveFile's d->tempFileName is a valid ODF file, it's under the same dir.

I think the reason could be that the temporary file is still open. Windows cannot rename files that are opened at least afaik. The problem is that KTemporaryFile/QTemporaryFile::close() does *NOT* close the file/file-descriptor;

bool QTemporaryFileEngine::close()
{
    // Don't close the file, just seek to the front.
    seek(0);
    setError(QFile::UnspecifiedError, QString());
    return true;
}

What means that the temporary file will stay open as long as it's used making it impossible to rename it during it's lifetime and when it's actually closed it#s to late cause it's autoRemove'd means deleted :-/

Does that make sense?

There btw is a

bool QTemporaryFileEngine::rename(const QString &newName)
{
    QFSFileEngine::close();
    return QFSFileEngine::rename(newName);
}

which does really close the temporary-file using the QFSFileEngine::close() rather then the overloaded QTemporaryFileEngine::close(). But KDE does not use that as you just wrote by uses the WinAPI direct bypassing the QTemporaryFile special-case :-/

Suggestion would be to not use KSaveFile in KArchive. Just create the archive and check later or on write if writing/saving it failed....

If my assumption above is true then just creating any QTemporaryFile zip-file using KArchive would always fail. It should be rather easy to make a simple test-case but since I do not have a KDE windows devel setup any longer... :-/

Yes, that makes a lot of sense to me.

So assuming you deductions are correct (sounds plausable) how would we go around making the best long term solution:

You suggest not using KSaveFile in KArchive, but wouldn't that just leave other users of KSaveFile to rediscover the bug. So wouldn't the best solution be to fix KSaveFile somehow? 

For the windows packaging of Calligra we should be able to patch KDElibs ourselves, so we wouldn't have to wait for a bug fix release of KDElibs. Or at least that is what I assume.

Created attachment 69347 [details]
Patch for KSaveFile that maybe fixes the issue

re KSaveFile; the current code and with it the bug is gone with Qt5/kdeframeworks ( for the case http://mail.kde.org/pipermail/kde-frameworks-devel/2011-October/000003.html will be or already is applied ) but yes, we should still fix it for the time being till Qt5/kdeframeworks is out and a Calligra-version based on it is ported and a Calligra@Windows version of it done and so on. Attached patch should fix it (all untested - it would rock if someone with a windows devel-setup could test if that really fixes the issue this bugreport is about).

Comment on attachment 69347 [details]
Patch for KSaveFile that maybe fixes the issue

I had to add .toLocal8Bit() to both arguments before I could compile, but after that I was sorry to see that the problem persists.

Fixed in bf47fed5ead06f2128abf042897f86bab39cf333