SBA: Component changed to "framework". Reassigned to TM

Hi grgustaf,

thanks for using and supporting OpenOffice.org...

This is reproduceable here on Solaris, too...

mci -> mav:
Hi mav, I think this is something for you. Please ressign, if this nothing in
your area., thanks...

mba: retargetted due to heavy workload

I thought of a more exciting example of the bug:

1. Open Word Processor
2. File | Save As, type name: a.b.c.d, save.
3. Save As, change type to .stw, save.
4. Save As, change type to .doc, save.
5. Save As, change type to .txt, save. Etc.

The files created are: a.b.c.d.sxw, a.b.c.stw, a.b.doc, a.txt

I was able to replicate the bug with Open Office 1.1 on a Linux OS and with Open
Office 1.4 on a Windows XP OS.

The problem, it seems, is that Open Office, in some cases, interprets the
contents after the last dot in the filename as an extension. 

I did some follow-up testing and it appears that not all possible strings (after
the last dot in filename) are interpreted as extensions. For example 0, foo,
blah, 1, p … are not interpreted as extensions whereas c, x … are interpreted as
extensions. Thus if an attempt is made to save a text file under a name such as
someName.foo, no problems occur and the file is saved as someName.foo.sxw. But
if an attempt is made to save some text file under a name someName.c, c gets
interpreted as an extension and the file is saved under the name someName.c
instead of being saved under someName.c.sxw.

It also appears that the bug is not specific to just Text Documents but spills
over to Presentation, Spreadsheets and Drawings.

Reproduceable on the following system:
System: Linux 2.4.26 Intel Celeron 766MHz 128MB RAM
OpenOffice.org 1.1.0

Tried the following two additional tests:
1) If file names with more than one consecutive dot are used, e.g. a.b..c.d or
a.b.. , this will prevent the application from mistaking any part of the file
name before the consecutive dots as an extension.
2) It is even possible to use dots only as a file name, e.g. chosing ... as file
name results in ....sdw as the saved file for instance. Of course this file will
be hidden in the Unix directory and can be viewed with the "ls -a" command.

Until this bug is fixed one can work around the problem by selecting the full
name with the previously saved extension before switching extension, i.e. click
on a.b.c.sxw before switching to extension .rtf in the example of grgustaf

I'm working on the presentation in the m92 and the file name is
co-prinese-2.0.odp. I decided to save it in the sxi format, so
I did File -> Save As, file type change and the file name was
truncated to the co-prinese-2.sxi, should be co-prinese-2.0.sxi.

Changing Version and the Target milestone, because it's quite
important and this Issue should be solved in the final 2.0.

TM->AS: Please have a look, thanks !

AS->MVA: Please take over. THX.

I was wondering why this Issue is not listed in the OOo 2.0 Issues
and I got it, target milestone is back to the OOo Later :( I think
that this Issue should be solved in the OOo 2.0 and I'm ready to
fix this, I found where the problem is, but need small advice which
direction is better.

The problem is here - lcl_autoUpdateFileExtension function is
called each time when the filter is modified or when the
checkbox 'Automatic file name extension' has been toggled. This
function expects file name with extension, but the problem is,
that the file name is here without an extension even if there
is 'Automatic file name extension' (AFNE) checked.

Few ways how to fix it:

  a) add extension to the file name during file picker dialog
     initialization (if AFNE is checked), so the extension will
     be visible from the same beginning

  b) do not show the extension in the file name even if AFNE is
     checked (same behaviour like Microsoft Office)

  c) leave it as it is and add more logic to check the extension handling,
     it means, add function which will examine the file name and the
     possible extensions from the previous filter and if there will be
     match, modify extension in the filename otherwise leave the file
     name as it is even if there will be AFNE checked

Who is responsible for the UI behaviour?

rvojta @ ft: Please, can you review my last comment and tell me which
solution is the best one (or propose new) for the end users? Then
reassign this Issue back to me, I'll fix it. Should be fixed for the
2.0 even if there is OOo Later. Thanks!

*** Issue 21282 has been marked as a duplicate of this issue. ***

Created attachment 25854 [details]
Automatic file name extension logic removed - do not change file name

Attached patch changes the generic fpicker behaviour - do not change
file name even if the check box is checked -> behave in the same way
as Gnome, MS Office fpickers ...

Created attachment 25862 [details]
Solution c) - leave logic and check the extensions before modification

Attached patch doesn't modify the behaviour, it justs fixes the extension
handling - extension is changed only and only if the part after the file
name's last dot is same as the last filter extension.

fs->rvojta: I'm in charge of the file picker, so lemme add my comments to this

a) does sound bad. Though there never has been a full specification for the file
dialog, I remember that on various occasions, the User Experience (UE) Team
wanted wanted the extension not to be shown by default. I know that this is a
rather fuzzy argument :), but I suppose showing the extension always is not what
UE would support.
Furthermore, it would only move (though relax) the problem, since the user might
remove the extension explicitly, and then switch the filter -> same problem again.

I'm not sure if I like b) (even if a certain competitor does it this way :).
Finally, it means that the user only knows what's going on after it's too late.
Given that extensions have a rather high importance (we may like or dislike this
fact), I would not be happy with not telling the use which extension her file is
going to have.

c) sounds like the best solution - it's a comprehensive fix, and still leaves
the user with a glue what's going on.

fs->ft: If you agree to the argueing that c) is the best solution, I'd be
willing to give rvojta's fix a review (it looks goot at a first glance).
Somebody would still have to decide on a target milestone then.

Created attachment 25955 [details]
Patch for the c) option

rvojta->fs: I attached the last version of this patch (-c-2.diff), which
was already accepted by mmeeks in the ooo-build.

hello,
i don't understand in this issue something,
first issue 21282 is older and is closed as resolved,
second the problem of saving in *.dot must be a litter problem as here discussed
and tried to be resolved,
When i have a file in *.doc i can renaime it in *.dot, so i ask me why it will
be so a long discussion about this, i don't understand from programming, but
including in writer as a saving option in *.dot will be so difficult because it
has the same format like *.doc.
Mybe i can help with this comment to solve the problem
grüsse stefan

Problem is still in OOo 1.9.113 on Win XP Pro.

Has a decision about which of the patches for options a,b, or c been applied to
OO 2.0 beta 2?

I'm guessing not. Defect verified present in 2.0 beta 2

FT: Patches will not go into 2.0. They need to get evaluated by the correct
engineer.

FT: Please check patch based on solution c) from rvojta posted on Sun Apr 24
01:10:00. Thx a lot.

Created attachment 30698 [details]
ooo-build's fix for this issue

I've created "different" patch for this issue. It was accepted by Mikael Meeks
and is part of the ooo-build patch set for a long time .

It's a last attachment - fpicker-generic-extn.diff

Thanks for providing this patch! Looking at it, there's one real issue and two nits:
- it has the potential to crash in FilterSelectHdl_Impl:
    const String& rLastFilterExt = pThis->_pImp->GetCurFilter()->GetExtension();
  Since GetExtension returns a String, not a reference to a String, this means that
  rLastFilterExt potentially points to dead memory as soon as it's assigned.
Depending
  on your compiler, this might or might not be a problem.
- in GetFsysExtension_Impl, it's probably better to not ignore the case. Other
places in
  the file make ignoring the case dependent on the platform, see for instance
  FindFilter_Impl.
  However, given that case handling is incorrect, anyway (normally it should depend
  on the case-sensitiveness of the concrete folder, not on the case-sensitiveness
  of the platform where you compiled the product), this probably doesn't really
hurt ...
- In
    if ( rFile.Copy( p1 - p0 + 1).EqualsIgnoreCaseAscii( rLastFilterExt ) )
      return String( rFile.Copy( p1 - p0 + 1 ) );
  the second Copy seems superfluous - returning rLastFilterExt directly would be
  better (and slightly and unnoticable faster :)

I addressed the first and the third item above, and checked the fix into CWS
dba202a. Again, thanks for the patch!

*** Issue 56790 has been marked as a duplicate of this issue. ***

*** Issue 56758 has been marked as a duplicate of this issue. ***

First of all - I am not a programmer so I don't understand half of the 
comments :v( 
 
When you open the document/file sometthing.xxx.yyy.zzz it has the filename 
extension (.zzz) then the program should split the filename in two parts: 
- Part one - the filename without extension (sometthing.xxx.yyy) 
- Part two - the filename extension (.zzz). 
 
Everytime you will Save As then it only has to change the filename extension 
and not the filename without extension. 
 
If you create a document then the filename extension would be the default 
which should be shown in the Save As dialogbox - don't hide any part of the 
filename for the user. 
 
You could use these filenames as test examples: 
 
filename-test-file.odt select .ott should give filename-test-file.ott 
filename-test-file.odt.odt select .ott should give filename-test-file.odt.ott 
filename-test-file-1.2.3.odt select .ott should give 
filename-test-file-1.2.3.ott 
filename-test-file....odt select .ott should give filename-test-file....ott 

*** Issue 57881 has been marked as a duplicate of this issue. ***

fs->tm: please verify in CWS dba202a

re-open issue and reassign to tm@openoffice.org

reassign to tm

reset resolution to FIXED

Checked and verified in cws dba202a -> OK !

closed