Linux/Manjaro problems saving files

[rsmith-ft]

When opening of saving a file the pop-up window only show the Desktop and Document directories and doesn't show any other directory in my root file tree.
When saving a file, the pop-up window says it saves the file to the root directory, but it doesn't. Its lying to me!
Manjaro 6.1.16-1 (64 bit)
RARS 1.6

[TheThirdOne]

It seems unlikely this is a RARS bug rather than a swing issue. If this issue persists beyond a restart of RARS, I would be 95% confident it is a swing issue.

If a RARS restart changes the behavior: the relevant code is

rars/src/rars/venus/EditTabbedPane.java

Lines 671 to 730 in 7acf325

	// Private method to generate the file chooser's list of choosable file filters.
	// It is called when the file chooser is created, and called again each time the Open
	// dialog is activated. We do this because the user may have added a new filter
	// during the previous dialog. This can be done by entering e.g. *.txt in the file
	// name text field. Java is funny, however, in that if the user does this then
	// cancels the dialog, the new filter will remain in the list BUT if the user does
	// this then ACCEPTS the dialog, the new filter will NOT remain in the list. However
	// the act of entering it causes a property change event to occur, and we have a
	// handler that will add the new filter to our internal filter list and "restore" it
	// the next time this method is called. Strangely, if the user then similarly
	// adds yet another new filter, the new one becomes simply a description change
	// to the previous one, the previous object is modified AND NO PROPERTY CHANGE EVENT
	// IS FIRED! I could obviously deal with this situation if I wanted to, but enough
	// is enough. The limit will be one alternative filter at a time.
	// DPS... 9 July 2008
	private void setChoosableFileFilters() {
	// See if a new filter has been added to the master list. If so,
	// regenerate the fileChooser list from the master list.
	if (fileFilterCount < fileFilterList.size() ||
	fileFilterList.size() != fileChooser.getChoosableFileFilters().length) {
	fileFilterCount = fileFilterList.size();
	// First, "deactivate" the listener, because our addChoosableFileFilter
	// calls would otherwise activate it! We want it to be triggered only
	// by MARS user action.
	boolean activeListener = false;
	if (fileChooser.getPropertyChangeListeners().length > 0) {
	fileChooser.removePropertyChangeListener(listenForUserAddedFileFilter);
	activeListener = true; // we'll note this, for re-activation later
	}
	// clear out the list and populate from our own ArrayList.
	// Last one added becomes the default.
	fileChooser.resetChoosableFileFilters();
	for (FileFilter ff : fileFilterList) {
	fileChooser.addChoosableFileFilter(ff);
	}
	// Restore listener.
	if (activeListener) {
	fileChooser.addPropertyChangeListener(listenForUserAddedFileFilter);
	}
	}
	}//////////////////////////////////////////////////////////////////////////////////
	// Private inner class for special property change listener. DPS 9 July 2008.
	// If user adds a file filter, e.g. by typing *.txt into the file text field then pressing
	// Enter, then it is automatically added to the array of choosable file filters. BUT, unless you
	// Cancel out of the Open dialog, it is then REMOVED from the list automatically also. Here
	// we will achieve a sort of persistence at least through the current activation of MARS.
	private class ChoosableFileFilterChangeListener implements PropertyChangeListener {
	public void propertyChange(java.beans.PropertyChangeEvent e) {
	if (e.getPropertyName() == JFileChooser.CHOOSABLE_FILE_FILTER_CHANGED_PROPERTY) {
	FileFilter[] newFilters = (FileFilter[]) e.getNewValue();
	FileFilter[] oldFilters = (FileFilter[]) e.getOldValue();
	if (newFilters.length > fileFilterList.size()) {
	// new filter added, so add to end of master list.
	fileFilterList.add(newFilters[newFilters.length - 1]);
	}
	}
	}
	}

[TheThirdOne]

I cannot reproduce this on my Linux/Arch system so you will need to provide a little more information if you want me to debug it for you.

[rsmith-ft]

I would like to preface my remarks about the RARS installation. The version of RARS is 1.6 and was installed from Flatpacks. I have uninstalled the Flatapacks version and re-installed and the new installation the same problem.

Also, I attempted to install RARS from following the Github instructions and it was problematic. I discovered that my java links in /usr/bin/ pointed to /usr/lib/jvm/default instead of /usr/lib/jvm/java-19-open/… I reinstalled java, however the links did not change so I edit the /usr/bin links to point to the java-19-open directory.

After changing the links, the Github version of RARS did install on my system, but did not run, so I went back to the Flatpak version of RARS.

The fundemental RARS problem is a disconnect between the RARS application and the Manjaro operating system.

What does work: Using Dolphin, if I double click on a *.asm file, RARS opens the proper file and it will run all tasks. Saving the *.asm file is a different story. Fig 1 shows that RARS will save the file in the /run/flatpak/do/af6310e0 directory. However, as the Dophin window shows in Fig 1, the operating system doesn’t have a /ru/flatpak directory. Further a search for an i-node named 146310e0 comes up empty.

Figure 1

Figure 2 show RARS shows “testuser” contains only two directories. The Dophon window shows there are 9 directories in the home file system.

  Figure 2

So, generally speaking the is a disconnect between the RARS application and the OS file system. I have no idea where to begin to trouble shoof from here.

[TheThirdOne]

So, generally speaking the is a disconnect between the RARS application and the OS file system. I have no idea where to begin to trouble shoot from here.

The key is to notice the file path /run/flatpak/do/af6310e0. You would not expect "flatpak" to show up unless flatpak is somehow interacting with the file paths. Based on that, you would expect this issue to not be about RARS per se, but instead about the flatpak packaging of RARS or flatpak itself.

You might google "flatpak cannot save file" and find a similar issue on Signal with a solution:

flatpak override --filesystem=home org.signal.Signal

Translating that to relevant to RARS would get you to

flatpak override --filesystem=home io.github.TheThirdOne.rars

which you could test to see if it would solve the problem (which it should unless you are editing .asm file in the root or something).

Alternatively if you are aware for flatpak sandboxing, the issue is pretty obvious. It just comes down to how you want to solve it; the command above may not be the best solution for you.

After changing the links, the Github version of RARS did install on my system, but did not run, so I went back to the Flatpak version of RARS.

RARS does not have an installation step. It is distributed as a Java JAR file which is directly runnable either from a file browser like Dolphin or on the command line like java -jar rars1_6.jar. This of course depends on having Java installed, but any reasonably recent Java version should work.

This is the only issue left. I would like to solve any friction to using RARS without flatpak. It seems unlikely that it is an error in RARS, but removing thorns that prevent certain system configurations from working is worth it. If you could provide any error messages or info about how the Github version failed to run, that would be greatly appreciated.