Making immutable attribute persistent

[Leee]

I'm using Core 17.0 on x86_64

Is there a handy way to get the "immutable" attribute of a file to persist across a backup and restore cycle?

My issue is this:  I have an application (emelfm2) that insists on changing the value of a certain setting in its config file to its default value when the program is closed and restarted.

Alarmingly, it does this even when the config file's ownership is changed to root:root and all write permissions are removed and the application is -not- running as root..

Using chattr to set the immutable attribute solves the problem,  but doesn't survive a reboot with backup and restore because the file is restored without "immutable" set..
As one-off, I could put a line in bootsync.sh to set the immutable attribute, but that feels clumsy so I'm looking for a more elegant solution.

• use persistent HOME, which I don't want to do
• remaster the emelfm2 extension to include the config file on r/o media (which would prevent me from ever changing any other setting)
• use a different file manager, which I don't want to do

but none of those really seem ideal either.

The file in question is ~/.config/emelfm2/config-C.

The setting within the file has to do with the way file dates are displayed.  There is a drop down list to select any of several preconfigured date formats (all of which are stupid) or "strftime() format provided below" with a box to enter a custom time format.  When the setting resets to default, it doesn't lose the custom format, it just forgets that its supposed to actually use it.

I think emelfm2 is an abandoned application so, while it would be ideal to have the application fixed, I don't think that's going to happen.  I'm comfortable with making the config file immutable and, if I have to, I'll reinstate the immutability at boot time but I'm hoping someone will mention something I've missed that allows the immutable attribute to be saved.  Feel free to say, "Well, dumbhead, did you try ...."


Any ideas?

[Rich]

Hi Leee

... The file in question is ~/.config/emelfm2/config-C. ...

I just tried it under TC14 x86_64.
I selected strftime() and set the custom format to %Y%m%d.
Then I hit Apply and then Commit.
I closed emelfm2 and then opened it. The config file retained the custom format.
I then closed emelfm2 again. The config file reverted to "Default".

The config file also contains this note:

# emelFM2 (v 0.9.1)

# This is the emelFM2 configuration data file.
# It will be overwritten each time the program is run!

[Leee]

Hi Leee

... The file in question is ~/.config/emelfm2/config-C. ...

I just tried it under TC14 x86_64.
I selected strftime() and set the custom format to %Y%m%d.
Then I hit Apply and then Commit.
I closed emelfm2 and then opened it. The config file retained the custom format.
I then closed emelfm2 again. The config file reverted to "Default".

The config file also contains this note:

# emelFM2 (v 0.9.1)

# This is the emelFM2 configuration data file.
# It will be overwritten each time the program is run!

Yes that is my experience, too - it reverts the file the -second- time the application is restarted.  Actually, I think it reverts when the program -closes- the second time.

I've seen that comment about the config getting overwritten but that is the file that gets updated when you make config changes in the applications UI, and it seems to be the only file with anything having to do with the date format.  FWIW, I'm not (for once) making manual edits to the file - only using the application's settings interface - I just want my settings to "stick".

[patrikg]

Can you just

Code: [Select]

chmod u-w ~/.config/emelfm2/config-Cso the app can't write to it.

[Leee]

Can you just

Code: [Select]

chmod u-w ~/.config/emelfm2/config-Cso the app can't write to it.

That was the first thing I tried.  It writes to it anyway.  I find that annoying, but even more annoying is that changing the file ownership to root:root gets exactly the same result - it writes to the file anyway.  In the mean time, actions that I -wish- would be performed as root are denied.

[patrikg]

OK, Now we have to take tough measures.
Just try to:

Code: [Select]

sudo chattr +i ~/.config/emelfm2/config-C
And what file system do you use ?
Maybe you are using a file system that does not use any user rights.
That's why you can't get it to work.

[Leee]

This is in a subdirectory under /home/tc, so it's type "rootfs" according to the output of "mount".

The immutable attribute works as expected, as shown here:

Code: [Select]

tc@dolly:~/.config/emelfm2$ touch poop
tc@dolly:~/.config/emelfm2$ ls -l poop
-rw-r--r--    1 tc       staff            0 May 20 03:41 poop

tc@dolly:~/.config/emelfm2$ sudo chattr +i poop
tc@dolly:~/.config/emelfm2$ rm -f poop
rm: can't remove 'poop': Operation not permitted
tc@dolly:~/.config/emelfm2$ sudo rm -f poop
rm: can't remove 'poop': Operation not permitted

tc@dolly:~/.config/emelfm2$ sudo chattr -i poop
tc@dolly:~/.config/emelfm2$ rm -f poop
tc@dolly:~/.config/emelfm2$ ls -l poop
ls: poop: No such file or directory

A side effect of using "immutable" on the config file is that, when emelfm2 can't write to config-C (because the file is immutable), it writes to config-C.tmp~1 when it shuts down.  The next time it closes, it writes config-C.tmp~2 and so on.  It does not -use- those files the next time it runs.  Since those files start to build up pretty quickly, I wrote a wrapper script that deletes them before running the application.

As a dirty work around for the "losing the immutable attribute" issue, I added some logic to that wrapper script to also make sure config-C is immutable before running emelfm2.  I don't like it, but it works.

I found a thread on stackexchange from a couple of years ago where someone mentioned that gnu tar does not back up the immutable attribute and there were no plans to include such a feature.  Someone mentioned there that bsdtar can back up the immutable attribute.  That thread did not, of course, involve busybox tar, but I presume that busybox tar will likely not ever include features that gnu tar does not include.

[mocore]

ftr
in an attempt to get at the root of the problem

 i found the source on github.com @ tom2tom/emelfm2/
presumably the is where you build i from?
( emelfm2.net appears to be filled with spam and unmaintained  )

Code: [Select]

grep -e "configuration data file" -r ./tom2tom_emelfm2-master

./plugins/e2p_config.c: _("select configuration data file"),
./plugins/e2p_config.c: _("save configuration data file"),
./src/config/e2_option.c:   _("# This is the %s configuration data file.\n"


i tryed to read e2_option.c ( it has comments )
but tbh i dont have a clue  where the relevant parts wrt to your issues might be

perhaps relevant ? ...
https://www.freelists.org/post/emelfm2/e2-config-name

unfortunately the list search wont work as it says its not indexed
and no archive appears available , with out manual scraping 

fwiw 'site:https://www.freelists.org/archive/emelfm2 config' also gives no result