Created attachment 78454 [details] Schema to explain steps to the bug Problem description: Openning two different types of files (ie : ODS and ODF) don't keep the original filenames. Steps to reproduce: 1. in the Windows file Explorer, select 2 files with of diferent types (ie : titi.ODF & toto.ODS), and clich on Enter to open them together, 2. the name of each file is neither "titi.ODF" nor "toto.ODS" but "sans nom 1" and "sans nom 2" (French translation of something like "unnamed1" and "unnamed2"..), 3. if You modify a file and do "Save", the "Save as..." windows appears and You need to give a name, or replace the original ! If You test with two similary file types (ie: ODF & ODF, or ODS & ODS, ...), there is no problem. Original filenames are kept. Current behavior: - orginal filenames are not kept when You open diferent files in same time ! Expected behavior: - original filenames are kept, Operating System: Windows 8 Version: 4.0.2.2 release
I can reproduce the Effect with "LibreOffice 3.6.6.2 release " German UI/ German Locale [Build-ID: f969faf] {pull date 2013-04-03} on German WIN7 Home Premium (64bit): A document couple 1.ods and 2.odt will both be opened as "Unnamed" as reported. But that is not too unexpected because a rightclick after having selected both documents in WIN Explorer will show NEW as the action to be done with <Enter>. But I can't reproduce that behavior with other programs (but only checked 2 other file type couples). So this might be the normal WIN Explorer behavior OR it's a problem with LibO Installation that it modifies WIN so that those couples will be used as _Templates_ instead of documents what should be opened. Effect not visible when I open documents via OS Files dialog Might be WIN and/or version related, not reproducible with LibO 3.5.7.2 on Ubuntu11 (VirtualBox). I think it's an installation bug, although I am not sure. I did not check with what version that "really" started
Your analyse is correct. "New" is the default action when You select two different files and do a right-click on them ; There is no "Open" action too. I think the problem come from the installation process.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.1.2 or later): https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-03-03
Confirmed, still happens. Win 7 Pro 64-bit, LibO Version: 4.4.1.2 Build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432 Locale: fi_FI
*** Bug 76895 has been marked as a duplicate of this bug. ***
The problem comes from the Windows registry (so from the LO installer). But it can't be solve without breaking another feature. I did my tests with an ods and an odt file. For what I understood only the "New" command is allowed when you select both the files because odt and ods have the same "New" command : * "HK_CLASSE_ROOT\.odt" point to "HK_CLASSE_ROOT\LibreOffice.WriterDocument.1" where the "New" command is "HK_CLASSE_ROOT\LibreOffice.WriterDocument.1\shell\new\command = C:\Program…\soffice.exe -n %1" * "HK_CLASSE_ROOT\.ods" point to "HK_CLASSE_ROOT\LibreOffice.CalcDocument.1" where the "New" command is "HK_CLASSE_ROOT\LibreOffice.CalcDocument.1\shell\new\command = C:\Program…\soffice.exe -n %1" They don't have the same "Open" command : * "HK_CLASSE_ROOT\.odt" point to "HK_CLASSE_ROOT\LibreOffice.WriterDocument.1" where the "Open" command is "HK_CLASSE_ROOT\LibreOffice.WriterDocument.1\shell\new\command = C:\Program…\swriter.exe -o %1" * "HK_CLASSE_ROOT\.ods" point to "HK_CLASSE_ROOT\LibreOffice.CalcDocument.1" where the "New" command is "HK_CLASSE_ROOT\LibreOffice.CalcDocument.1\shell\new\command = C:\Program…\scalc.exe -o %1" So when you select both file and hit Enter, the "New" command is selected (as it's the only one available) and LO register the file as Untitled1.odt and Untitled2.ods. A simple workaround should be to change "HK_CLASSE_ROOT\LibreOffice.WriterDocument.1\shell\new\command" and "HK_CLASSE_ROOT\LibreOffice.CalcDocument.1\shell\new\command" to "C:\Program…\soffice.exe -o %1". It works but the icon for odt and calc documents on the desktop (not on the file explorer) became the LibreOffice one (not the Writer or Calc anymore). I believe it's a Windows bug since the icon should depend on the DefaultIcon registry key for desktop and the file explorer : https://msdn.microsoft.com/en-us/library/windows/desktop/cc144175%28v=vs.85%29.aspx
Do you think "multi-selection opening" is more important than documents icons on the Desktop ?
Created attachment 117131 [details] reg file to disable the creation of multiple documents when multi-selection I attached a reg file that disable the "multi-selection opening". If this patch is apply, when the user select multiple file of different type and hit Enter, nothing happen.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
Confirmed, still happens the bug. Win 10 Pro 64-bit, LibreOffice Versión: 5.2.1.2 Id: 31dd62db80d4e60af04904455ec9c9219178d620 Locale: es-ES (es_ES)
Confirmed too under Windows 10 64 bits LibreOffice 5.2.6.2 Build ID: a3100ed2409ebf1c212f504_fbe377c281438fdc Locale : fr-FR (fr_FR)
(In reply to Maxime de Roucy from comment #8) > Created attachment 117131 [details] > reg file to disable the creation of multiple documents when multi-selection > > I attached a reg file that disable the "multi-selection opening". > If this patch is apply, when the user select multiple file of different type > and hit Enter, nothing happen. Hello Maxime :) I tested your reg file and I got this as result: When I select two files with 2 different types (ODT and ODS), let's say I selected ODT file as the 1st one then the ODS file, I hit enter it shows up a pop-up (like the pop-up when I do right-click on a file and click on "open with" then "Choose another application"). and it says "How you want to open this .odt file", if I choose LO Writer then press OK, it only opens the 1st file which is the ODT file. When I repeat the same steps mentioned but I select ODS file as the 1st one it opens the ODS file as expected. BTW, I didn't lose the icons of LO calc nor wirter. I think this behavior is better than not doing anything. Thanks, nzoueidi
Created attachment 132825 [details] A workaround for this bug Hello, Based on thoughts of Maxime, I did a workaround for this bug by just changing "HK_CLASSE_ROOT\LibreOffice.WriterDocument.1\shell\open\command" and "HK_CLASSE_ROOT\LibreOffice.CalcDocument.1\shell\open\command" to "C:\Program…\soffice.exe -o %1". I have attached the reg file, BTW I did not had any problems related to icons (in the destop and in the file explorer) Thanks, nzoueidi
Hello, This is the patch[1] to keep the original names for two files with two different extensions. [1] https://gerrit.libreoffice.org/#/c/36995/ Best, nzoueidi
Polite ping: a patch is pending waiting for review. Thanks all for your time
Naeil ZOUEIDI committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ba0a94a914260c38abd8dc5af1104ba14734b8ef tdf#63913 fix Win explorer multi-select open unnamed docs bug It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thanks, Naeil, for your contribution!
The bugfix is wrong. It breaks the possibility to open certain filetypes (like .txt) using one of two available modules (like Calc or Writer) using the context menu. For those types, two "LibreOffice" elements are now displayed in the context menu, both pointing to generic action (opening with default filter, which - for .txt case - would be to open as plain text in Writer). One could create another element (like "Open in Writer/Calc/etc") with the specific command line. That would allow to keep the fix, while still providing the choice. (But that would make the menu to still have multiple redundant elements - need to check if certain elements could be omitted in the Open With menu).
Just a clarification: my comment 18 wasn't intended to be rude; now that I revisit it, I see that it sounds harsh - please excuse about that: English isn't my native language. What I intended to say is that some change is necessary.