bugGNU Octave - Bugs: bug #51439, Save file dialog not allowing file...

 
 

bug #51439: Save file dialog not allowing file to be saved on VMWare shared folder

Submitted by:  None
Submitted on:  Tue 11 Jul 2017 01:26:53 PM UTC  
 
Category: GUISeverity: 3 - Normal
Priority: 5 - NormalItem Group: None
Status: Wont FixAssigned to: None
Originator Name: Originator Email: -unavailable-
Open/Closed: ClosedRelease: 4.2.0
Operating System: GNU/Linux

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 Jump to the original submission)

Mon 17 Jul 2017 05:06:17 PM UTC, comment #9:

Great. Looks like you should take that up with VMWare. Their filesystem is telling you the maximum file name length is zero.

Mike Miller <mtmiller>
Project Administrator
Mon 17 Jul 2017 07:31:26 AM UTC, comment #8:

That does indeed return "0".

Anonymous
Fri 14 Jul 2017 05:53:56 PM UTC, comment #7:

If you do want to investigate, the Qt code is pretty clear on what tests it does to decide whether to enable or disable the Save button.

https://github.com/qt/qtbase/blob/5.9/src/widgets/dialogs/qfiledialog.cpp#L3493

Just by reading the code, the case that seems most likely to me is that the filesystem is returning 0 for the maximum file name length. This can be tested in the command shell with

If that returns a number greater than 0 (for example 255 on a typical Linux native filesystem), then it may take using a debugger to see when the button state is set to disabled.

Mike Miller <mtmiller>
Project Administrator
Fri 14 Jul 2017 05:45:41 PM UTC, comment #6:

So this seems like a bug in the VMWare shared folders filesystem emulation driver, or some missing aspect in how it works with what the Qt library is doing.

I don't think anything can be done about this in Octave, we are not going to recreate our own file dialog to work around this. I think the best way forward would be for you to report this to Qt to to VMWare customer support and see if you can get a resolution that way.

I'm closing this bug report as won't fix, but anyone can still comment and find this bug for future reference.

Mike Miller <mtmiller>
Project Administrator
Fri 14 Jul 2017 10:17:13 AM UTC, comment #5:

One more thing to add: This is only valid for creating a new file. If I add an empty file using "touch" first, all Programms happily write into that file.

Anonymous
Fri 14 Jul 2017 10:09:07 AM UTC, comment #4:

Hi Mike,

I tried with kate (and also with gnuplto 5 qt), and I can confirm your assumption. Neither kate nor the new gnuplot can save a file to the shared folder. Saving in any other folder works fine.

André

Anonymous
Thu 13 Jul 2017 05:36:13 PM UTC, comment #3:

The screenshot looks like your description, and I can't reproduce here without your exact VMWare setup.

I'm inclined to believe this may be a bug between Qt and VMWare's shared folders implementation, but I haven't found any open bug reports relating to that yet.

Can you try another Qt program, for example kate, kwrite, or retext? These are all text editors that you should be able to easily install from the Ubuntu repositories. Try saving a file in one of them to the same shared folder mountpoint and report back whether it behaves the same or not.

Mike Miller <mtmiller>
Project Administrator
Thu 13 Jul 2017 12:27:19 PM UTC, comment #2:

Thanks Mike. Attached is a screenshot with the grey save button. This was a test with Octave 4.2.0 64bit compiled, but it was exactly the same behaviour than with the 32bit "normal" octave version.

(file #41198)

Anonymous
Wed 12 Jul 2017 06:22:29 PM UTC, comment #1:

In my experience the Save button is only disabled when a file name has not been entered or selected in the dialog.

Qt does have some logic about the maximum name length allowed on a particular directory, so that could be of interest here. What is the length of the full path to the shared directory you are trying to save on?

Other than that I don't see any logic in Qt's file dialog about what type of directory or permissions on the directory that would cause the button to be disabled.

Please attach a screenshot, preferably from Octave 4.2.1, with what you are seeing, and the full path name of the mounted directory you are trying to save to.

Mike Miller <mtmiller>
Project Administrator
Tue 11 Jul 2017 01:26:53 PM UTC, original submission:

I use Octave on a VMWare virtual Ubuntu 16.04 on a MacHost. The issue occurs when I try to save a file onto the shared folder (e.g /mnt/hgfs/...) using the gui dialog box. Here, the "save" button is simply disabled. Saving into the home folder is possible.
However, using "save file.m" from the gui's command line works fine, even in the shared folders.

Runing Octave as root shows the same behaviour.

This happens on Octave 4.0.2 from the ppa octave:stable, as well as on Octave 4.2 build from source.

Anonymous

 

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

Attach File(s):
   
   
Comment:
   

Attached Files

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by mtmiller (Posted a comment)
  •  

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

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 14 Jul 2017 05:45:41 PM UTCmtmillerStatusWorks For Me=>Wont Fix
      Open/ClosedOpen=>Closed
      SummarySave file dialog not functioning on shared volume=>Save file dialog not allowing file to be saved on VMWare shared folder
    Thu 13 Jul 2017 12:27:19 PM UTCNoneAttached File-=>Added Bildschirmfoto vom 2017-07-13 14-16-54.png, #41198
    Wed 12 Jul 2017 06:22:29 PM UTCmtmillerStatusNone=>Works For Me

    Back to the top


    Powered by Savane 3.1-cleanup1