Issue 46480

Framework issue.

hi olio, version 1.1.3 is too old now.
please retest with 1.1.4 and / or latest milestone build.
both of them are available free of charge from our download section.

closing for now. please reopen if you can reproduce with 1.1.4 or latest
milestone build.

.

Retested problem on OpenOffice 1.9.74, where the problem is the same, only the 
folder used for backup files has changed to:

C:\Documents and Settings\Administrator\Application Data\OpenOffice.org1.9.74
\user\backup

TM->requirements: Please have a look. This is not a defect but seems to be worth
to think about our behaviour of backing up documents. So I set this one to
"enhancement"

Reset to OOo later.

This issue is simply to solve:
let's name the backup files after the full file name (with extension) of document:
test1.odt ->  test1.odt.bak
test99.ods ->  test99.ods.bak

But also there is another problem:
If you resave file from with backup:
\Document folder\Document_with_same_name.odt
then you save document with same name but from a different location
\Other document folder\Document_with_same_name.odt
the second document's backup overwrote the first one. Is this issue related to
this issue, or should I fill a new file?

or we can simply introduce a new set of extensions:

ob?


for example obt - for text backups
for example obd - for draw backups
for example obp - for presentations backups

etc.

sfx2/source/doc/docfile.cxx handles the backup:
void SfxMedium::DoBackup_Impl()

Same Problem under OO 3.0.

I think to fully solve this issue the Backups must be

1. named as the original file +bak. (so text.odt will bbe test.odt.bak and
test.ods will be test.ods.bak)
-  OR  - e ad other extensions like kami suggested
for example obt - for text backups
for example obd - for draw backups
for example obp - for presentations backups
etc.


and 
2. The backups must be in the same folder as the original files.
Thats the way it is in many applications including MSOffice.

Created attachment 74136

As given in description.
AOO410m1(Build:9750)  -  Rev. 1569541
Rev.1569541
Win 7

Looks like sfx2/source/doc/docfile.cxx
(http://aoodev1:8080/source/xref/current/main/sfx2/source/doc/docfile.cxx#2104)
is the file where the backup is created.

(In reply to Edwin Sharp from comment #12)
> As given in description.
> AOO410m1(Build:9750)  -  Rev. 1569541
> Rev.1569541
> Win 7

You also requested the show-stopper status for this issue.
Could you please give corresponding reasons, why should such an old issue become a show-stopper for the next release? Thx in advance.

bug 124106 got a show-stopper and AFAIK more users are using backup than pages 5.
despite issue age, backup is a feature that IMHO should work flawlessly as users rely on it as a savior.

I don't see that this issue will be fixed in time but if somebody is able to provide a fix we will integrate in 4.1. I don't see it directly as showstopper.

Created attachment 82734 [details]
Append .bak

Here is the simple solution: keep existing extension and append .bak.
Made some simple tests (on Windows), works well.

Created attachment 82736 [details]
Update

This time only the promised fix: Append not replace .bak

What happens if homework.ods in both Math directory and Physics directory?
IMHO full path for backup name more robust solution, i.e.:
C_Users_Edwin_Documents_Math_homework_ods.bak
C_Users_Edwin_Documents_Physics_homework_ods.bak

@Edwin: That is why I called it 'simple' solution and did not commit it.  For the inclusion of the path we first have to agree on a proper naming scheme.  The use of underscores to separate directory names for instance does not work when the directory names themselves contain underscores:

a/b_c/file and a_b/c/file would both be mapped to the same a_b_c/file.

Therefore we should think whether we want an improvement now (shortly after the release) or a perfect solution in the future.

Good solution later > Not a good solution now.
The perfect solution will know how to handle built in underscores and perform truncation when necessary according OS naming limitation.

@Edwin: As you wish, I have adapted importance accordingly.  Can you please reset the release blocker flag?

(In reply to Edwin Sharp from comment #15)
> bug 124106 got a show-stopper and AFAIK more users are using backup than
> pages 5.
> despite issue age, backup is a feature that IMHO should work flawlessly as
> users rely on it as a savior.

Some background on bug 124106 to make clear that it is not so easy to compare issues just by their summary:
- For bug 124106 corresponding related bugs exist, namely 123702, 123761 and 124058 - as given in my show-stopper status request. Four bugs recently submitted is an indication of the high relevance of this issue.
- Bug 124106 and the related ones show quite big drawbacks in our *.docx import filter which are in general not triggered by *.docx files created by Microsoft Office. But the documents are conform to the OOXML file format.
- Interoperability with documents in OOXML file format is one of the big important points for our users due to the made survey conducted last year.

Thus, please understand my question for the show-stopper status request for this issue.
This issue occurs in OpenOffice versions since 2004, it got no duplicates and no votes, and there was no activity on it since 2008. In my point of view this issue is far less important than 124106.

OK, thanks.
Do you think there is room for improvement in:
https://wiki.openoffice.org/wiki/Showstopper ?

Please store the backup-file in the same folder as the original, like other applications do. 

Together with appending "bak" (instead of replacing) there can be no problem.

g.marxen

"don't put all your eggs in one basket"

I'm against saving backup and original in the same location.

@g.marxen: The original file might be in a location that is unsuitable for backups (eg the template repository of a company).

@Edwin: Agreed, but I don't think that the use of backup in this context is not an insurance against drive failure but more a means against user error.

The backup-copy is not a real backup but the "last saved version" before the new version. So it makes sense to have it in the same folder as the actual "new" version. So you can easily go back to the "last" version, if f.e. the new version is corrupt, f.e. caused by a crash.

The bak-version is no substitute for a backup of the new version (and older versions) on a different disk drive (Server, NAS etc.). 

So if you have your eggs only on the build-in disk drive, it makes no difference, if new and bak-version are in different folders. 

Having them in one folder, there is no need to "construct" new file names to avoid conflicts. That's the big advantage over your proposal.

Please fix this issue for the next release.
Thank you for realizing its importance.

(In reply to g.marxen from comment #28)
> The backup-copy is not a real backup but the "last saved version" before the
> new version. So it makes sense to have it in the same folder as the actual
> "new" version. So you can easily go back to the "last" version, if f.e. the
> new version is corrupt, f.e. caused by a crash.
> 
> The bak-version is no substitute for a backup of the new version (and older
> versions) on a different disk drive (Server, NAS etc.). 
> 
> So if you have your eggs only on the build-in disk drive, it makes no
> difference, if new and bak-version are in different folders. 

But there are many related aspects. e. g. you have a USB stick which a large Document. (Yes documents especially with included pictures can be somewhat of big!) If you save the changed file and there is no more place left for a copy ... what should AOO do? At worst case you lost the file completely.


> Having them in one folder, there is no need to "construct" new file names to
> avoid conflicts. That's the big advantage over your proposal.

If you work on test.odt, test.ods and test.odp in the same folder you will have only one test.bak only for last saved file.


This behaviour is discussed since a long time ago. But I don't remember all the reasons why it wasn't changed. Maybe that a user have the right to edit files but not the right to create new files in the folder. Maybe the capability of OO edit documents via FTP and other protocols.
So the only "save" version is to save the copy at a place that is known that the user have the right to create a file.

(In reply to mroe from comment #30)
> 
> But there are many related aspects. e. g. you have a USB stick which a large
> Document. (Yes documents especially with included pictures can be somewhat
> of big!) If you save the changed file and there is no more place left for a
> copy ... what should AOO do? At worst case you lost the file completely.

Working on a USB-stick is like requesting for data loss, that might be OK with tiny files you can recreate in a minute. With large documents: good luck.

> If you work on test.odt, test.ods and test.odp in the same folder you will
> have only one test.bak only for last saved file.

You forgot the proposal to append .bak and not replace the original extension.

If it's not too much work for a developer there could be addionally an option for the "bak-path" in tools/options but then it could be more complicated to avoid any overwrite of bak-files.

(In reply to g.marxen from comment #31)
> > But there are many related aspects. e. g. you have a USB stick which a large
> > Document. (Yes documents especially with included pictures can be somewhat
> > of big!) If you save the changed file and there is no more place left for a
> > copy ... what should AOO do? At worst case you lost the file completely.
> 
> Working on a USB-stick is like requesting for data loss, that might be OK
> with tiny files you can recreate in a minute. With large documents: good
> luck.

It is quite clear for me and for you ... but AOO should respect all users ...

> > If you work on test.odt, test.ods and test.odp in the same folder you will
> > have only one test.bak only for last saved file.
> 
> You forgot the proposal to append .bak and not replace the original
> extension.

Sorry. I have overlooked comment 25.