SpaceFM - A Customizable File Manager

IgnorantGuru · 2014-01-20 22:57:14

Hi ninian, Welcome to the truly ugly side of FM dev. The situation for the last few YEARS has been that the XDG/MIME specs are not updated, and the whole desktop standard seems to have splintered into camps, eg KDE, GNOME, etc. Even the offical XDG tools don't follow what remains of their published specs (xdg-open bug report). Some discussion takes place or took place on the xdg mailing list, but what conclusions were reached, if any, were never published. FMs seem to use varying quasi-versions of the old defaults.list for app associations, which according to the latest almost-specs shouldn't even be used for this purpose.

Not knowing all of this, over a year ago I updated SpaceFM and brought it mostly up to spec - or what I thought was the spec. They have since muddied the language there, and added a comment "Do not use any of this in implementations at this point..." So what are you supposed to use to implement mime actions? It seems to be undefined - for years.

SpaceFM mostly follows that almost-spec, but from what I've heard it's the only file manager that does. Most ignore the mimeapps.list and still use a broken version of defaults.list. SpaceFM's behavior is documented fairly clearly here.

The upshot of all this is that SpaceFM is kind of in a world of its own. Associations you add in SpaceFM may not appear in other apps, and vice versa. I'm not inclined to spend any serious time on this unless they publish an actual spec. So for now I just tweak things a bit. Within SpaceFM it should work consistently at least. iow if you associate an app, it should stick and work as expected. But outside of SpaceFM it's simply unknown what affect it will have, depending on the app and what list file they're parsing, and what almost-spec they're using.

As for the subdirs in applications/ and the hyphens, my impression was that KDE started that (xscreensaver seems to put stuff there too). Your update-desktop-database info is news to me. First I became aware of it was in this SpaceFM issue 118. I didn't think I had accomodated the hyphens, but I see this commit that seems to indicate I did something for it. I don't even know how SpaceFM works! Then came issue 227, where KDE apps were listed but wouldn't work, etc.

The change in 0.9.3 just brought consistency within SpaceFM. Earlier changes made it look into the applications/ subdirs, but other parts of SpaceFM didn't, which resulted in 'command not found' errors.

So don't look for any sanity here. It's just a creeping standard, and I accomodate it slightly here and there, but I don't spend any serious time on it. SpaceFM just dives into the subdirs if it can't find a referenced .desktop file. And it does accomodate the hyphens somewhat (but I don't think it uses them when writing associations to mimeapps.list.

Anyway I try to ignore it as best I can. The person I recommend speaking to is Vladimir Kudrya - an active SpaceFM tester. He's investigated this and opened that xdg-open bug. He tried to get me to make SpaceFM work like other apps until he realized that SpaceFM is actually more up-to-date on the specs than any of them. But he can tell you quite a bit. Let me know if you'd like me to ask him to email you - not sure if his email is published.

To me this isn't all by accident - I think Red Hat is undermining anything they touch in Linux, basically driving it into the ground. But that's a whole other rant.

ninian · 2014-01-21 00:42:48

IgnorantGuru wrote:

Hi ninian, Welcome to the truly ugly side of FM dev ....
Anyway I try to ignore it as best I can. The person I recommend speaking to is Vladimir Kudrya - an active SpaceFM tester. He's investigated this and opened that xdg-open bug. He tried to get me to make SpaceFM work like other apps until he realized that SpaceFM is actually more up-to-date on the specs than any of them. But he can tell you quite a bit. Let me know if you'd like me to ask him to email you - not sure if his email is published.

Many thanks for the comprehensive reply and the interesting links.
Yes, I could see that KDE and GNOME were causing havoc with the hyphens!
Quite why the so-called "standards" have been allowed to wither so much is beyond me, and the xdg-utils tools are pretty awful, as you say.
I think your .desktop implementation in SpaceFM is very good and pragmatic - certainly better than just about every other FM I can think of.
The approach I'm taking for fyr is similar to your own, doing what I can with the main sensible features but not losing any sleep over it.
Now I think I've got some routines which are working to accommodate the subdir-name1-name2.desktop and subdir/name.desktop problems, and hopefully won't need to bother Vladimir yet.
Much appreciated!

Lockheed · 2014-01-27 07:47:30

It seems like starting from the last spaceFM update, I lost the ability to see live changes in directories I am viewing.

Before, if I deleted a folder, it disappeared from SpaceFM. Now, I have to press F5 to see it gone.
Before, during file coppying, I could see ongoing increase of target file size. Now, it stays static until I press F5.

ninian · 2014-01-27 08:47:09

Lockheed wrote:

It seems like starting from the last spaceFM update, I lost the ability to see live changes in directories I am viewing.

Yes, I've encountered this too - 64-bit GTK3 version.

Lockheed · 2014-01-27 21:24:28

ninian wrote:

Lockheed wrote:
It seems like starting from the last spaceFM update, I lost the ability to see live changes in directories I am viewing.
Yes, I've encountered this too - 64-bit GTK3 version.

I am using 64-bit GTK2 version, and it is getting particularly annoying when working with removable devices. It won't even update list view for unmounted USB stick, and if I mount another one in the same place, F5 still shows files from the old USB.

IgnorantGuru · 2014-01-28 14:33:59

Re needing to refresh with F5: There have been no recent changes to the code which handles this, and no reports of this problem on other distros. Could this be some problem with Arch's inotify (kernel) support? Any messages on stderr when running spacefm in a terminal? Does spacefm-git also show the problem (for build comparison)?

You might want to file a bug report on the spacefm package in Arch so the packager can look at any build issues or other changes related to this. At present this looks like an Arch-specific issue not triggered by recent changes in SpaceFM.

Lockheed · 2014-01-28 15:06:03

IgnorantGuru wrote:

Re needing to refresh with F5: There have been no recent changes to the code which handles this, and no reports of this problem on other distros. Could this be some problem with Arch's inotify (kernel) support? Any messages on stderr when running spacefm in a terminal? Does spacefm-git also show the problem (for build comparison)?

I got the output. I am running "spacefm -d", so this is the output from the main session:

** (spacefm:12065): WARNING **: Failed to add monitor on '/home/juha/Desktop/AE/ISO/avira' ('/home/juha/Desktop/AE/ISO/avira'): No space left on device
EXEC(/home/juha/.local/share/applications/k3b-usercreated-0.desktop)=k3b

** (spacefm:12065): WARNING **: Failed to add monitor on '/home/juha/Desktop/AE/ISO' ('/home/juha/Desktop/AE/ISO'): No space left on device

File deletion happens before or after the last line.

I am using BTRFS and have about 20GB space left on that partition.

IgnorantGuru · 2014-01-28 16:31:29

Lockheed wrote:

I got the output. I am running "spacefm -d", so this is the output from the main session:
...
I am using BTRFS and have about 20GB space left on that partition.

That is a fairly low level error coming from the kernel (inotify_add_watch() is failing with the error "No space left on device", which seems like an odd error to cause a watch failure). So SpaceFM is unable to add a watch via inotify on that directory. btrfs is notorious with having 'space remaining' issues, so this could represent a bug in btrfs and/or in the related kernel inotify support, perhaps part of a recent update in Arch. If it's happening with other fs's, inotify looks like the problem.

jfyi, SpaceFM can also be built with fam/gamin support by using configure option --disable-inotify. In that case a fam or gamin server is required to be running. This support is deprecated and not quite as responsive, but might provide a quick workaround until the inotify problem is sorted in Arch.

EDIT: Here is the code in SpaceFM that generates the warning you're seeing. As you can see not much to go wrong there - just inotify_add_watch returning an error.

Last edited by IgnorantGuru (2014-01-28 17:04:00)

fabertawe · 2014-01-28 16:33:16

Lockheed wrote:

ninian wrote:
Lockheed wrote:
It seems like starting from the last spaceFM update, I lost the ability to see live changes in directories I am viewing.
Yes, I've encountered this too - 64-bit GTK3 version.
I am using 64-bit GTK2 version, and it is getting particularly annoying when working with removable devices. It won't even update list view for unmounted USB stick, and if I mount another one in the same place, F5 still shows files from the old USB.

No such problems here - 64bit GTK2. All drives EXT4 if that's any help.

IgnorantGuru · 2014-01-28 17:06:10

Actually the errno being returned (ENOSPC, normally "No space left on device") is defined by inotify_add_watch() as meaning "The user limit on the total number of inotify watches was reached or the kernel failed to allocate a needed resource." Probably the latter.

Last edited by IgnorantGuru (2014-01-28 17:08:22)

Lockheed · 2014-01-28 18:59:35

So is that something related to kernel parameters set during kernel compilation? I am using -pf kernel.

IgnorantGuru · 2014-01-28 19:27:29

Lockheed wrote:

So is that something related to kernel parameters set during kernel compilation? I am using -pf kernel.

I would suggest reporting this as a kernel-related bug in Arch. inotify has been in the Linux kernel since 2.6.13. I'm not sure what kernel build options affect it, but this looks like outright breakage of some kind. The problem could be localized in btrfs also. There's also a slight chance it could be a weird build problem with SpaceFM and the sys/inotify.h headers, but that is unlikely since it built successfully. If no obvious causes present themselves, I would look in the inotify_add_watch() source for what specific conditions generate an ENOSPC error (but this is more something for Arch kernel developers to look at I would think, or failing that, upstream).

If you want to take SpaceFM completely out of the loop, you can probably generate the same error by manually setting a watch using inotify-tools (which is a package containing inotify related CLI tools, but this package is not used by SpaceFM, which calls the kernel directly.)

IgnorantGuru · 2014-01-28 22:28:43

As this got a bit complex, I added a clear bug report here on Bartłomiej's spacefm package. There is nothing to indicate a packaging bug, but he's probably the best person to troubleshoot it or may know where to send it. I recommend adding reports to that bug detailing what filesystem(s) are affected, and any system or kernel specifics that may narrow it down. And he may ask for some testing by those affected so would be helpful to watch that bug.

Last edited by IgnorantGuru (2014-01-28 22:34:30)

IgnorantGuru · 2014-01-28 23:21:38

Well, just to be helpful, an uninterested third party already closed the bug report with a nonsensical comment, so no further information can be added. At least Bartłomiej knows the situation this way. Contrary to the (falconindy) comment there, there is no indication of a large number of watches being added - he ignored the OR in the meaning of ENOSPC. (Although you might check to make sure some other program isn't creating a large number of watches, hitting the system limit.) There is no indication this can be corrected upstream in spacefm, and I'll be taking no further action on it. But feel free to ask if I can be of general help. If any upstream action is indicated, feel free to file an issue on spacefm's tracker.

Last edited by IgnorantGuru (2014-01-28 23:52:40)

Lockheed · 2014-01-29 22:45:13

I just tested if the same behaviour is exhibited by nemo file manager. And no, it is not.

ninian · 2014-01-29 23:08:28

It's a few days since I checked, and have now fully upgraded system. SpaceFM seems to be behaving as expected again. If I delete files or folders (say in a terminal) with SpaceFM open, it is automatically refreshing to show them gone. As IgnorantGuru suggested, this (for me anyway) maybe has been a problem with other packages or the kernel itself (it's been upgraded too). Will report back if problem returns and try to get more details.

vasyabelkin · 2014-02-27 17:48:48

Hello, IgnorantGuru.
I'm using 0.9.3 64b installed from default Arch package on KDE 4.12.2. I have a problem with panels sizes. Recently I've started from scratch and immediately saw the issue (this is reproducible with an empty config, e.g 'spacefm -c /tmp/spacefm-conf'). I maximize the window, open second panel side by side, reconfigure columns width and close it (with or without 'Save session' - it doesn't matter). Upon reopening, the second panel enlarges and takes 70-80% of screen width, instead of 50%. Please note, that I'm not using SpaceFM to manage desktop, nor in daemon mode, so the desktop is loaded completely, and only then I start SpaceFM manually and maximized, but in the 'session' file I see the following:

[Window]
width=640
height=480
maximized=1

Although the real resolution is 1920x1080.

Could you, please, look at the issue? Thank you very much

IgnorantGuru · 2014-02-27 19:33:13

vasyabelkin wrote:

Hello, IgnorantGuru.
I'm using 0.9.3 64b installed from default Arch package on KDE 4.12.2. I have a problem with panels sizes. Recently I've started from scratch and immediately saw the issue (this is reproducible with an empty config, e.g 'spacefm -c /tmp/spacefm-conf'). I maximize the window, open second panel side by side, reconfigure columns width and close it (with or without 'Save session' - it doesn't matter). Upon reopening, the second panel enlarges and takes 70-80% of screen width, instead of 50%. Please note, that I'm not using SpaceFM to manage desktop, nor in daemon mode, so the desktop is loaded completely, and only then I start SpaceFM manually and maximized, but in the 'session' file I see the following:
[Window]
width=640
height=480
maximized=1
Although the real resolution is 1920x1080.
Could you, please, look at the issue? Thank you very much

Thanks, sounds this this issue which has been corrected for the next release. You can test the fix by installing spacefm-git from AUR, or follow the BUILD NEXT instructions in README. Also, the issue includes a workaround for 0.9.3. Basically this bug affected people who maximized the window on first run.

The window width/height refers to unmaximized size.

vasyabelkin · 2014-02-27 21:00:13

OK, the workaround works. Thank you!
Feature request: could you, please, show the size of a panel in percents, relative to the SpaceFM window size, when dragging the sliders? It'll be easier to adjust them this way.
One more thing I cannot find in 0.9.3: is there a way to assign a shortcut key to move between panels?

Thank you, IgnorantGuru, for your hard work

IgnorantGuru · 2014-02-28 01:23:09

vasyabelkin wrote:

OK, the workaround works. Thank you!
Feature request: could you, please, show the size of a panel in percents, relative to the SpaceFM window size, when dragging the sliders? It'll be easier to adjust them this way.
One more thing I cannot find in 0.9.3: is there a way to assign a shortcut key to move between panels?
Thank you, IgnorantGuru, for your hard work

To focus a panel, use View|Go|Panel... You can assign shortcut keys to those menu items.

Feature requests are best placed on the tracker if you don't want it to get lost.

vasyabelkin · 2014-02-28 18:00:48

Yes, I've looked for the option to focus next panel in the context "Go" menu, but it wasn't there, so I thought this feature is not supported anymore, as I didn't remember how I succeeded to define it in previous installation.
About the feature request, I will place it on the tracker.

Thank you!

orschiro · 2014-04-22 06:55:30

Hi there,

To me it is not clear how I can move/copy a selected folder to one of my bookmarks in the side-pane?

Drag and drop (as known from other file managers) does not work for me.

Tips appreciated.

whatshisname · 2014-04-22 14:20:04

Position yourself in the folder you want to bookmark. Then from the menu: Bookmarks/Add.

orschiro · 2014-04-22 16:29:57

@whatshisname

You misunderstood my issue. I know how to bookmark a folder. But I cannot see how to drag&drop files into a bookmarked place in the sidebar.

whatshisname · 2014-04-22 16:38:47

@orschiro

Ah. Sorry. Yeah. I don't think you can do that now.

What you can do, though, is open a tab for the folder you want to drop files into and drag into that tab.

Not exactly what you want but close.

Arch Linux

#626 2014-01-20 22:57:14

Re: SpaceFM - A Customizable File Manager

#627 2014-01-21 00:42:48

Re: SpaceFM - A Customizable File Manager

#628 2014-01-27 07:47:30

Re: SpaceFM - A Customizable File Manager

#629 2014-01-27 08:47:09

Re: SpaceFM - A Customizable File Manager

#630 2014-01-27 21:24:28

Re: SpaceFM - A Customizable File Manager

#631 2014-01-28 14:33:59

Re: SpaceFM - A Customizable File Manager

#632 2014-01-28 15:06:03

Re: SpaceFM - A Customizable File Manager

#633 2014-01-28 16:31:29

Re: SpaceFM - A Customizable File Manager

#634 2014-01-28 16:33:16

Re: SpaceFM - A Customizable File Manager

#635 2014-01-28 17:06:10

Re: SpaceFM - A Customizable File Manager

#636 2014-01-28 18:59:35

Re: SpaceFM - A Customizable File Manager

#637 2014-01-28 19:27:29

Re: SpaceFM - A Customizable File Manager

#638 2014-01-28 22:28:43

Re: SpaceFM - A Customizable File Manager

#639 2014-01-28 23:21:38

Re: SpaceFM - A Customizable File Manager

#640 2014-01-29 22:45:13

Re: SpaceFM - A Customizable File Manager

#641 2014-01-29 23:08:28

Re: SpaceFM - A Customizable File Manager

#642 2014-02-27 17:48:48

Re: SpaceFM - A Customizable File Manager

#643 2014-02-27 19:33:13

Re: SpaceFM - A Customizable File Manager

#644 2014-02-27 21:00:13

Re: SpaceFM - A Customizable File Manager

#645 2014-02-28 01:23:09

Re: SpaceFM - A Customizable File Manager

#646 2014-02-28 18:00:48

Re: SpaceFM - A Customizable File Manager

#647 2014-04-22 06:55:30

Re: SpaceFM - A Customizable File Manager

#648 2014-04-22 14:20:04

Re: SpaceFM - A Customizable File Manager

#649 2014-04-22 16:29:57

Re: SpaceFM - A Customizable File Manager

#650 2014-04-22 16:38:47

Re: SpaceFM - A Customizable File Manager

Board footer