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

[Leee]

Thanks for digging into that, mocore.

I took a look at e2_options.c  and it doesn't seem to be the relevant file.  Sadly, it's been way too long since I've slung any non-trivial C code and now my brain hurts.

if I get into fixing the application myself, it will likely be a matter of months before I get anywhere - I'm woefully behind the times in programming tools and such, so maybe that would be good for me anyway.   

[Juanito]

Does the same thing happen with emelfm (gtk1 version of emelfm)?

[Leee]

Does the same thing happen with emelfm (gtk1 version of emelfm)?

emelfm doesn't keep any files under ~/.config but it keeps several under ~/.emelfm and it tries to overwrite all of them when the program is closed.  It does respect file permissions on those files - won't write a file that's not "writable".

As far as the file date format is concerned, it doesn't look like emelfm provides a way to set that.

[Rich]

Hi Leee

... As far as the file date format is concerned, it doesn't look like emelfm provides a way to set that.

I took a look at:

Code: [Select]

emelfm2 --helpand figured out how to set that:

Code: [Select]

emelfm2 --set-option="date-string=strftime() format provided below"
I started and stopped emelfm2 4 times like that and it it used
the strftime() format every time. The config file retained that
setting each time too.

I have a file in my .X.d directory to fix the menu entry of gparted for me:

Code: [Select]

tc@E310:~$ cat .X.d/FixGparted
[ -f ~/.wmx/Applications/gparted ] && echo -e "#!/bin/sh\nexec sudo /usr/local/bin/gparted" > ~/.wmx/Applications/gparted
tc@E310:~$
You could try something similar for emelfm2:

Code: [Select]

[ -f ~/.wmx/Applications/emelfm2 ] && echo -e "#!/bin/sh\nexec /usr/local/bin/emelfm2 --set-option=\"date-string=strftime() format provided below\"" > ~/.wmx/Applications/emelfm2
That would fix the menu entry. I'm not sure how to fix the icon.

[Leee]

Hi Leee

... As far as the file date format is concerned, it doesn't look like emelfm provides a way to set that.

I took a look at:

Code: [Select]

emelfm2 --helpand figured out how to set that:

Code: [Select]

emelfm2 --set-option="date-string=strftime() format provided below"
I started and stopped emelfm2 4 times like that and it it used
the strftime() format every time. The config file retained that
setting each time too.

I have a file in my .X.d directory to fix the menu entry of gparted for me:

Code: [Select]

tc@E310:~$ cat .X.d/FixGparted
[ -f ~/.wmx/Applications/gparted ] && echo -e "#!/bin/sh\nexec sudo /usr/local/bin/gparted" > ~/.wmx/Applications/gparted
tc@E310:~$
You could try something similar for emelfm2:

Code: [Select]

[ -f ~/.wmx/Applications/emelfm2 ] && echo -e "#!/bin/sh\nexec /usr/local/bin/emelfm2 --set-option=\"date-string=strftime() format provided below\"" > ~/.wmx/Applications/emelfm2
That would fix the menu entry. I'm not sure how to fix the icon.

As usual, you've hit upon the "right" solution.  There was I, trying to use sledge hammer when a kinder, gentler leather mallet was the right tool for the job.  Embarrassingly I had looked at the the help text from "emelfm2 --help" and failed to realize that I could do what you did - I guess because the help text didn't explicitly say anything about "date" or "format".

For fixing the icon, I already have a script that substitutes my wrapper script for the main binary in .wbar, so I'll either just change that to run the main binary with that option or, more likely, add the option to the wrapper script and do away with most of the rest of the logic in the wrapper.

While this solves the emelfm2 issue, which was the end goal,  it doesn't solve the "immutable attribute not persistent" issue, which I don't think is really solvable w/o persistent HOME.  It also doesn't solve the issue where emelfm2 seems able to ignore ownership/permissions of its config file, which is no longer an issue except in as much as it might be symptomatic of something bigger and which is what necessitated using "immutable" in the first place.

Two side subjects:

• emelfm2 crashing seemingly (but not really) randomly for which I'll open a thread in "TCE Talk"
• a generic script for replacing the icon, text or command for an item in .wbar, for which I'll open a thread in "TCE Talk" when it's ready

[Rich]

Hi Leee

... Embarrassingly I had looked at the the help text from "emelfm2 --help" and failed to realize that I could do what you did ...

I didn't catch it the first 3 times I read it either.

[mocore]

>Thanks for digging into that, mocore.
noproblem

  Sadly, it's been way too long since I've slung any non-trivial C code and now my brain hurts.

gui complexity can do that  ,... why not downgrade  ... for piece of mind
to something simpler-ish 

https://github.com/huijunchen9260/fm.awk - File manager written in awk

this one ( written in ashell) is even in the repo! 

>Re: tinycommander
>minimalistic busybox Almquist shell (ash) to approximate a file manager (similar to midnight or norton commander).

posted to tc-17.x x86 repo