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.
|
Mon 17 Jul 2017 07:31:26 AM UTC, comment #8:
That does indeed return "0".
|
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.
|
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.
|
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.
|
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é
|
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.
|
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)
|
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.
|
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.
|