bugGNU Octave - Bugs: bug #56298, [Windows] File Browser...

 
 

bug #56298: [Windows] File Browser "rename" operation deletes file when only changing case of file name

Submitted by:  None
Submitted on:  Fri 10 May 2019 11:21:28 AM UTC  
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Missed Error or Warning
Status:  Ready For Test Assigned to:  None
Originator Name:  Originator Email:  -email is unavailable-
Open/Closed:  Open Release:  dev
Operating System:  Microsoft Windows

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Mon 27 May 2019 04:33:19 PM UTC, comment #15: 

Well, no response so I went ahead and pushed the patch.  Maybe it will help.

Rik <rik5>
Project Administrator
Mon 20 May 2019 10:16:43 PM UTC, comment #14: 

Should I apply the patch?  It doesn't affect behavior on non-Windows platforms, and it might cure the issue on Windows.

Rik <rik5>
Project Administrator
Tue 14 May 2019 06:33:00 PM UTC, comment #13: 

It may be the difference between Windows OS versions.  There isn't much harm in moving to using QFile.rename instead of QDir.rename, and if it solves the issue then we're done.

Seems like a testable way out of this would be to apply the patch, create an MXE install package, and have the original bug reporter download and try on his/her computer.

Rik <rik5>
Project Administrator
Tue 14 May 2019 06:28:36 PM UTC, comment #12: 

@jwe: I think we should have a bug fix release soon-ish, although not necessarily driven by this particular bug.  The 5.1.0 release was 2/23/19 so we will be coming up on 3 months soon.  That is fairly arbitrary, but could be enough of an incentive.  It looks like there have been 35 non-documentation bug fixes since release.  I've attached a summary list.

(file #46909)

Rik <rik5>
Project Administrator
Tue 14 May 2019 05:09:06 PM UTC, comment #11: 

That was the using octave from the offical 5.1.0 win64 installer

So, I am not seeing the issue reported  on the bug - I can however replicate it with my test program in comment #4.

But am not sure why I dont see it in the GUI

John Donoghue <lostbard>
Project Member
Tue 14 May 2019 04:05:23 PM UTC, comment #10: 

John D:  Are the results you report in comment #9 with the 5.1.0 version we distribute or a patched/updated version?

This problem seems fairly serious.  Is it time for 5.2.0?  Or just a patched installer that fixes only this problem?

John W. Eaton <jwe>
Project Administrator
Tue 14 May 2019 12:00:24 PM UTC, comment #9: 

On my system, windows 10 pro, 64bit
version 1809, build 17763.437

On the file browser, I create a folder on my local drive (home directory) and then in it, using the file beowser menu, create a folder test1.m, and a foldertest2

Right click on test2 folder and select rename and rename as TEST2 -> worked ok

Right click on test1.m and rename as TEST1.M -> worked ok

create a new file test2.m, and then right click on it and rename to TEST1.M -> silently fails but the TEST1.M and test2.m files are still there

I also tried the "lower.txt" to "LOWER.TXT" rename and works for me

John Donoghue <lostbard>
Project Member
Tue 14 May 2019 07:25:45 AM UTC, comment #8: 

Thanks for the quick answers!
Additional Information on System:
Windows 10 Enterprise, Version 1803, Build 17134.706
I just tried the case mentioned below:
renaming "lower.txt" to "LOWER.TXT" removes the file too.

Renaming a directory does nothing: name and case are not changed, no error message.

Anonymous
Mon 13 May 2019 10:05:04 PM UTC, comment #7: 

@John: So renaming "lower.txt" to "LOWER.TXT" works in the GUI?

Maybe need to collect more information from the original reporter about the particular version of Windows, etc.  Windows 10 seems to have many more quirks than previous versions.

Rik <rik5>
Project Administrator
Mon 13 May 2019 07:31:36 PM UTC, comment #6: 

Well to muddy the waters a little more, I dont see the issue in the file browser in octave, despite seeing it in example program

John Donoghue <lostbard>
Project Member
Mon 13 May 2019 07:17:42 PM UTC, comment #5: 

This is such a bother.  If I had to guess, they applied some sort of fix to the rename() member function in QFile, but neglected to do the same to QDir.  So, if we're nice, we should probably file an upstream bug about that.

I suppose we have to work around it until they fix it.  I tested and QFile.rename seems to work for both files and directories.  This patch should be enough

diff -r 4092ffc1e43c libgui/src/files-dock-widget.cc
--- a/libgui/src/files-dock-widget.cc   Fri May 10 22:15:37 2019 +0200
+++ b/libgui/src/files-dock-widget.cc   Mon May 13 12:14:37 2019 -0700
@@ -671,7 +671,8 @@ namespace octave
             // editor: close old
             emit file_remove_signal (old_name, new_name);
             // Do the renaming
-            bool st = path.rename (old_name, new_name);
+            QFile f (old_name);  // Must use QFile, not QDir (bug #56298)
+            bool st = f.rename (new_name);
             // editor: load new/old file depending on success
             emit file_renamed_signal (st);
             // Clear cache of file browser

Attached is a complete changeset for testing.

(file #46900)

Rik <rik5>
Project Administrator
Mon 13 May 2019 05:17:03 PM UTC, comment #4: 

We are using 5.12.1 in the 5.1.0 release.

Doing a quick qheck in windows, it appears that QFile.rename behaves differently to QDir.rename

ie:

QFile("lower.txt").rename("LOWER.TXT") will return all ok,

however

dir.rename("lower.txt", "LOWER.TXT") will fail

My test program:

// compiled:  g++ testrename.cpp -I /mingw64/qt5/include -L/mingw64/qt5/lib -DQT_CORE_LIB -lQt5Core
#include <QtCore/qfile.h>
#include <QtCore/qdir.h>

int main()
{
  qDebug("running test");

  unlink("QtSoftware.txt"); unlink("qtsoftware.txt");

  // create file
  {
    QFile file("qtsoftware.txt"); file.open(QIODevice::WriteOnly); file.close();
  }

  // rename test
  {
    QFile file("qtsoftware.txt");

    if(!file.rename("QTSOFTWARE.TXT"))
    {
      qDebug("file error %s", qPrintable(file.errorString()));
    }
    else
    {
      qDebug("file rename was ok");
    }

    unlink("QTSOFTWARE.TXT"); unlink("qtsoftware.txt");
  }

  // create file
  {
    QFile file("qtsoftware.txt"); file.open(QIODevice::WriteOnly); file.close();
  }

  // test QDir
  {

    QFile file("qtsoftware.txt");

    QDir dir(".");

    if(dir.rename("qtsoftware.txt", "QTSOFTWARE.TXT"))
    {
      qDebug("Qdir error %s", qPrintable(file.errorString()));
    }
    else
    {
      qDebug("QDir rename was ok");
    }

    unlink("QTSOFTWARE.TXT"); unlink("qtsoftware.txt");
  }

  return 0;
}

John Donoghue <lostbard>
Project Member
Mon 13 May 2019 04:05:08 PM UTC, comment #3: 

Thanks.  I changed the Summary to more accurately describe the problem.  Marking as Confirmed, althoug I can only test on a Linux platform where this works.

The issue is going to be in libgui/src/files-dock-widget.cc.

  void files_dock_widget::contextmenu_rename (bool)
  {
    QItemSelectionModel *m = m_file_tree_view->selectionModel ();
    QModelIndexList rows = m->selectedRows ();
    if (rows.size () > 0)
      {
        QModelIndex index = rows[0];

        QFileInfo info = m_file_system_model->fileInfo (index);
        QDir path = info.absoluteDir ();
        QString old_name = info.fileName ();
        bool ok;

        QString new_name
          = QInputDialog::getText (this, tr ("Rename file/directory"),
                                   tr ("Rename file/directory:\n")
                                   + old_name + tr ("\n to: "),
                                   QLineEdit::Normal, old_name, &ok);
        if (ok && new_name.length () > 0)
          {
            new_name = path.absolutePath () + '/' + new_name;
            old_name = path.absolutePath () + '/' + old_name;
            // editor: close old
            emit file_remove_signal (old_name, new_name);
            // Do the renaming
            bool st = path.rename (old_name, new_name);
            // editor: load new/old file depending on success
            emit file_renamed_signal (st);
            // Clear cache of file browser
            m_file_system_model->revert ();
          }
      }

  }

We are using Qt's rename function from the Qdir class.  The documentation for that is

bool QDir::rename(const QString &oldName, const QString &newName)

Renames a file or directory from oldName to newName, and returns true if successful; otherwise returns false.

On most file systems, rename() fails only if oldName does not exist, or if a file with the new name already exists. However, there are also other reasons why rename() can fail. For example, on at least one file system rename() fails if newName points to an open file.

If oldName is a file (not a directory) that can't be renamed right away, Qt will try to copy oldName to newName and remove oldName.

See also QFile::rename().

It seems possible that Qt is trying to copy oldName to newName, which probably fails on Windows when the file name only differs by case, and then instead of aborting it goes on to remove oldName.

That could be tested in a stand-alone Qt program.

Actually, a little more Google digging shows that this is a known error for Qt versions less than 5.10.  See https://bugreports.qt.io/browse/QTBUG-3570.

What version of Qt does MXE-Octave version 5.1.0 ship with?

Adding John D. to the CC list for the answer to the last question.

Rik <rik5>
Project Administrator
Mon 13 May 2019 07:53:56 AM UTC, comment #2: 

The issue appeared when renaming a file in the File Browser, Octave 5.1.0 running on Windows 10.
Steps to reproduce:
- create new file in editor
- save file as e.g. Test.m
- In File Browser: right click, Rename
- change name to test.m
Result: file disappers from file browser (and from filesystem too)

Using rename in the command window does not delete the file, the command returns an error and the case is not changed.
e.g. rename Test.m test.m
ans = -1

Anonymous
Fri 10 May 2019 09:44:51 PM UTC, comment #1: 

Does this mean you have trouble when using the file browser window in the GUI?  Or is it that you are executing the command rename() in the Command Window and this fails?

Rik <rik5>
Project Administrator
Fri 10 May 2019 11:21:28 AM UTC, original submission:  

When renaming a file in the GUI under windows changing only the case (e.g. uppercase to lowercase initial letter) the file is deleted and not renamed without error message or warning.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #46909:  stable_bugs_fixed.list added by rik5 (3KiB - application/octet-stream)
file #46900:  bug56298.cset added by rik5 (1KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by lostbard (Posted a comment)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by rik5 (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-05-27 rik5 StatusPatch Submitted => Ready For Test
        Release5.1.0 => dev
    2019-05-14 rik5 Attached File- => Added stable_bugs_fixed.list, #46909
    2019-05-13 rik5 Attached File- => Added bug56298.cset, #46900
        StatusConfirmed => Patch Submitted
    2019-05-13 rik5 StatusNeed Info => Confirmed
        SummaryFile deleted when renaming => [Windows] File Browser "rename" operation deletes file when only changing case of file name
        Carbon-Copy- => Added lostbard
    2019-05-10 rik5 StatusNone => Need Info

    Back to the top


    Powered by Savane 3.5