I was orignally an Amiga user and one of the draws to BeOS was that Tracker does spatial very well - resizing windows, moving icons around in icon view is all automatically ‘snapshotted’, as we Amiga users would say
However, the read-only packagefs areas don’t do this - if you open the /boot/system/apps folder and resize/move it, all spatial settings are lost when you open it again.
This seems like a tricky problem to solve, because as I understand it, the position of the window, size and icon layouts are stored in that folder as metadata. It would need some kind of mirrored folder structure elsewhere on disk that is writable, and changes to Tracker to know to store/retrieve the spatial information from there for the packagefs areas.
Any thoughts or ideas about this? I could be alone thinking this is actually much of a problem
For me, this is behavioral and not a mystery. If something is virtual and write-protected, you can not save anything there. The question would be at this point whether it would make sense to create the data on the position of the windows in an external file in the write-permission area, so that one even in the write-protect area the windows always gets as much as one would like. On the other hand a user in the system area as a rule nothing to look for and therefore this would be for me no important reason here something to change.
We need to re-think the way we handle this anyway. While storing the spatial data as file attributes sounds nice at first (takes not much space, is fast, is preserved when copying the file, etc), there is the problem that you can’t change a read-only folder, and there is also the problem that this does not support multiple users having the same files with different positions and other settings.
I’m not sure there is a good way to solve that. Ideas welcome
Well if we are looking way into the future when multiple users are enabled, the way to do it is have each user’s settings for size/sorting/etc on each directory node saved as a settings file in their ~/config/settings so that if settings are found there for a node it overrides the default.
I too have noticed on one or more of my Haiku instances that the system directory is not sorted by name, so every time I open it I need to resort it.
I agree. Configuring how and where any folder is displayed should always be possible. Our current system didn’t only break down with the virtual, “read-only” folders introduced with package management. It never worked on read-only mounted volumes and non-BFS partitions.
Having one settings file per folder may not be the most efficient way, but generally there’s probably no other way that can handle all situation of dealing with non-writable or non-attributing file systems. I have no idea about the resulting speed penalty, though…
Maybe some smart caching system can soften the impact? Or some VFS magic…
The current setting should also continue to be written to the folder’s attributes. Thereby copying the folder will retain the setting, the thing PulkoMandy mentioned.
All settings for opened and adjusted read only folders can be stored in one tracker’s settings file, maybe one per volume.
…Maybe tracker can make mirrored (in some settings file) zipped folders and files links with attributes, and use that to display read only folders content and window position?
This feature can be optional.
The settings file is not the best place, but some other file next to it could work.
As for the performance, I’m not too worried, if we chose an appropriate data structure (fast lookup using node ref as index? if that works accross reboots), it should be fine since that file would be used quite often, Tracker could keep it open.
However, it has another drawback: it is specific to Tracker. Some other features also rely on attributes: storing the play position and volume in a media file, storing the line and column in a text file, etc. It would be nice to have a generic solution for all these needs, too.
Yeah… I must say though, it’s a bit disappointing. BeOS and Haiku were uniquely elegant with the use of attributes in the file system. Now it looks like for the sake of interoperability with other file systems, read-only file systems, and even within Haiku due to the read-only virtual file system of package management, we’re about to give up on that.
Maybe it’s a necessary step. Maybe there’s a dual-way of keep using attributes and only have another mechanism as transparent fallback. On the other hand, developing that fallback to work as well as the direct attribute way, there may not be much reason to cling to the attributes…
The attributes work very well for files in the user directory, and we have several cases where we do that and it works just fine: e-mails, people files, etc.
They do have their limitations, however. As mentionned: they need specific FS support so interoperability is a concern, they can’t be written on read-only drives, and, I think most importantly, they don’t work as well in multi user contexts.
This does not mean we should stop using attributes altogether. It only means we must be aware of these restrictions. We can decide to live with them (not being able to write attributes on a read-only file seems totally sane to me), maybe we can find workarounds (storing attributes in some other ways on less featureful filesystems), and maybe we can somehow manage to remove the restrictions (for example, if we design a new filesystem for R2, we could think about a different way to store attributes so they can be (optionally) user-specific).
I don’t think attributes are going away at the user-visible level in any case. How we implement them under the hood so the feature continues to work as expected is a different matter.
Sorry I didn’t mean to imply that. Instead some fast database structure, which Tracker references and keeps a cached version in memory for fast access and the settings file database as the permanant record across reboots. Or perhaps this needs to be rolled into the file system to take care of any attributes that may be altered on a file/directory. But I am in no way a filesystem guy so I could be talking out my you-know.
One drawback I just though of about using a settings file is when moving between Haiku installs on different partitions any changes to attributes on read only files/directories will not follow you since you will be using a different /boot/home.
Sounds like a job for a virtual file system layer that intercepts writes and passes reads on to the read-only file system.
The written data would be stored in a file in the current user’s home directory. That way each user could have their own modifications to the read only file system saved separately.
This is essentially the solution Microsoft went with since Vista. There’s a “virtual” directory that overlays the read-only admin directories, and reads and writes go there first.
We do have a write_overlay filesystem (used for the LiveCD so the home directory is writable there). However, this was never set up to collaborate with PackageFS, for multiple reasons:
It is currently not possible to save the “written” files with write_overlay. The setup would be lost at each reboot (the files are stored only in RAM).
The “read-only” part of package FS is not that static, it can change with system updates and when installing packages. Think about what should happen if you install a lib manually in the write overlay, then install a package that contains the same library.
There is of course a performance overhead when doing that, and it would slow down the whole system.
No one has implemented any of the above.
There are other interesting problems with the way attributes work in packageFS. For example, the “apps” directory in the Haiku package is set with its attributes as they were before PackageFS: large 32x32 icons. However, several other packages have an “apps” directory inside them. When the PackageFS reads the directory attributes, IIRC it picks them from a single one of the packages, and you don’t know which. As a result, you rarely get the expected ones from the Haiku package, and are more likely to get a set of attributes from another random package. I’m not sure if this was already fixed, at some point we considered “merging” the attributes from all packages in such a case.
https://en.wikipedia.org/wiki/Spatial_file_manager
