Locked window properties of read-only folders

[humdinger]

This is hrev46218.

Window properties (size, position, displayed attributes, sorting order etc.) of read-only folders can - unsurprisingly - not be modified.
So for example, the first app package installed in ~/config/packages will create the ~/config/apps folder with the properties used in that package. Can't be changed. Should be especially interesting if that package came from a developer working in a localized system, as that would even have localized attribute column names...

Can there be a solution to this problem?

[Not sure in what ticket category to put this...]

[leavengood]

I am surprised no one has ever really commented on this, it feels like a fairly big problem caused by the package management switch.

Could a simple solution just be that Tracker maintains some sort of "database" with the attributes of read only folders? Maybe the file path of the folder can be made into a sha1 hash and use that as a file name to associate attributes with under something like ~/config/tracker/folder-attributes/?

[pulkomandy]

I am surprised no one has ever really commented on this, it feels like a fairly big problem caused by the package management switch.

There is not much to comment about. It's indeed a problem (I see that I have already upvoted it) but I don't have a good idea what to do about it.

[leavengood]

I will add this to my list to look at eventually. I had taken #13976 which was a duplicate of this.

Since the folders are read-only their names can't change so I feel like storing the folder attributes in some files under ~/config seems okay, either as files named after the folder path (with / replaced with - or _), or just as a hash of the name (maybe with the path as an attribute so they are less opaque.) It also means your folder settings can move with your home directory even on new installs.

Though adding this to the Tracker code might be troublesome but I haven't looked at it in a while.

[bitigchi]

Isn't R1.1 milestone a bit late for this? Preserving size and position of read-only folders would be expected from a "stable" system that offers a real "spatial" desktop. Looking at probono's Haiku ​video about this, it's the first thing he tries, and if I remember correctly he mentioned this bug in his article series as well.

[pulkomandy]

It's not possible to do this to read-only folders in BeOS. So, technically, this does not belong in R1.

Note that it doesn't mean it won't get done before then. But we are trying to keep the definition of R1 stable. If we keep adding things to it, no progress is made, because the milestone keeps moving further away as we go.

R1 is only the first release of Haiku. It is not the end of our work, but only the start.

If you think this is an important problem, you can upvote it (I already did, because I agree it is an important and useful feature). That will have more effect than adding comments about which milestone things should be in.

[bitigchi]

I thought BeOS had it, since it seemed like a basic feature. Thanks for the info!

[pulkomandy]

BeOS like Haiku stores this data in attributes of the directory. If the directory is read-only, it is not possible to write the attributes to it. Therefore, any changes made, are not stored. If the attributes are present, they will still be read.

The onyl way to fix that would be to store the attributes "elsewhere". This will probably mean some centralized place somewhere in the user settings. As a result:

• They will be lost if you rename or move the folder (assuming they identify the folder by its name/path)
• They will be lost if you copy the folder
• They will be lost if you zip the folder to move it to another computer
• They will not be deleted when you delete the folder. Over time, you will end up with a huge list of outdated attributes filling your disk

I am personally not happy with that solution. And I don't have a better idea. I think the behavior of "read-only folders can't store these changes because they are read-only" is, after all, maybe the least confusing option.

Maybe we should, however, make it more easily visible that a given folder is read-only. Show a lock icon somewhere, maybe?

[bitigchi]

For the record, hello has an active ​discussion revolving around the same subject.

Would it be possible to create a readable/writeable properties file inside these folders?

Or, creating a central query that would track the folders and their properties which have the "read-only" attribute of some sort? If the mentioned folder is deleted, and cannot cross reference that folder, it would delete the entry.

Or to simplify things, it can be accomplished via a daily script that runs and checks the read-only folders around the file system. In either case it should be trivial to keep that database clean.

[nephele]

My suggestion would be to have packagefs have a feature to persist specific attributes with a kind of "overlay" package, this might work since packagefs already deals with packages anyway, this would only require it to have a partial knowledge of how to write a .hpkg that would overwrite atributes.

I don't see much point to try and implement this for other RO storage, since it is.... well, read only, but for packagefs that is atleast our design decisison to do it this way, not an inherit property of the medium.

[pulkomandy]

Would it be possible to create a readable/writeable properties file inside these folders?

The initial problem is "the folder is read-only". By definition of "read-only", it is not possible to write anything inside it. That's the problem. For writable folders the existing code works just fine.

Or, creating a central query that would track the folders and their properties which have the "read-only" attribute of some sort

A query or script cannot track when a folder is moved or renamed.

I don't see much point to try and implement this for other RO storage, since it is.... well, read only, but for packagefs that is atleast our design decisison to do it this way, not an inherit property of the medium.

Maybe a package-fs specific option can be designed. It is possibly not as simple as it seems, however. System directories already exist in several packages (every package with an app in it has a copy of the /system and /system/packages directories, for example). The initial implementation of packagefs would get the attributes from one of these, at random. I think it has been changed in some way to always get the attributes from the haiku package in priority.

Essentially this comes back to the main design limitation of packagefs: at the time we didn't manage to implement transparent write support with acceptable performance (it was implemented, but it made everything even slower than it is now). Maybe doing it in a more restricted way only for attributes may work.

Since packagefs knows when things happens to directories (when they are deleted by removing a package, for example), it could keep the list of stored attributes clean. Probably using an hpkg is not the most efficient way, but maybe something could be stored in the administrative dir.

It can still lead to some potentially confusing situations. For example, if you try to delete an attribute that exists both in the writable overlay and in the underlying packages, it will probably result in the attribute being reverted to what's in the packages. I think that's still better than what we have now?

The question of performance remains however. We'll have to see if this is possible without too much of a performance hit.

[humdinger]

Maybe we should, however, make it more easily visible that a given folder is read-only. Show a lock icon somewhere, maybe?

See #10122, though the lock icon presented there is quite ugly...

WRT to storing properties: I was wondering, if the HPKG of an app itself could be used to store properties as attibutes, thus avoiding having to write inside the package. That would maybe work for the app specific folders inside that package, but doesn't solve things that are shared among packages, like the /system/apps folder...

It's a conundrum. Probably the reason why nobody came up with a solution yet for 7 years... :)

[leavengood]

Replying to pulkomandy:

The only way to fix that would be to store the attributes "elsewhere". This will probably mean some centralized place somewhere in the user settings. As a result:

• They will be lost if you rename or move the folder (assuming they identify the folder by its name/path)
• They will be lost if you copy the folder
• They will be lost if you zip the folder to move it to another computer
• They will not be deleted when you delete the folder. Over time, you will end up with a huge list of outdated attributes filling your disk

It definitely is not ideal to have to have folder attributes in a different location than the folder, but I think all these concerns are overblown. For one thing you won't be renaming or moving a read-only folder, so I think the first concern is not valid. Though in general I think all these concerns except zipping could be addressed by node monitoring.

I believe implementing this in libtracker.so just to solve this specific problem is easier than trying to hack something into the package system.

Also I believe that while it is true that BeOS has the same limitation for read-only folders this is a regression from BeOS because the package system made previously writable system folders read-only. I am overall a fan of the package system but this is definitely a drawback and I think we should try to fix it.

Obviously my rate of work for Haiku development has been extremely slow or non-existent for some time, but once I wrap up some financial related work for Haiku, Inc I hope to spend more time on proper Haiku development. When I do I'll try to experiment with this as one of the first things I do.