guess it should have a config file, but cannot find where.

another question: is there a way to 'trace' where a binary file have it's config file? (as ldd does to show dependencies)

thanks in advance

What do you want to configure exactly? The only purpose of tune2fs is to change some parameters of an existing ext2/3 filesystem. As far as I am aware there's no config file related to tune2fs, and I can't think what it would be useful for either...

To find the config files related to any tool the best place to start looking is the tool documentation. In the man pages usually config files are referenced, some man pages also have a section called "SEE ALSO" at the end where related config files and additional tools or whatever are shown as well. Tools that lack a man page maybe has an info one, or readme files under /usr/share/doc, if nothing else, then go to the tool home page and look around.

right, usually such data (config files) figure in the app's man page. but this one's doesn't mention config files.

do you know where does it save custom configurations? (really dont think it re-compile by itself saving new parameters in its code)

I think any app which is configurable, have to save such configurations somewhere.

what I want is to override just one option of it configuration, but I'm affraid that changing one, others will adopt a default value -and mabye this value is not the one setted right now.
maybe it have an option kinda --show-actual-settings, so after my modification I could call it again to see if something else was changed and -if so, to set back to it previous vaules.
but, let's agree that to reach directly the config file and to change just X parameter is more easy.

thanks for answering.
hasta la vista!

But what configuration are you speaking about? tune2fs is a command line tool, what kind of behavior is that that you want to modify? It would be like a config file for chmod, I can't imagine what would you want to change about tune2fs at all.

You usually use tune2fs like this (just some examples)

There's nothing configurable in it, you just use switches to set special properties on your filesystems. And once you set the property, it's there forever, as long as you don't change it again. If you describe exactly what is that that you want to achieve I might be able to help.

thanks for you answers.
as I imagine, there are (huge) difference between chmod and tune2fs.
-of course, I can be quite wrong on his- so, let's go step by step.

chmod sets(modify) r/w properties of the file which is passed as last parameter. the 'holder' of such properties is the file by itself.
(you can trick a config file for chmod where to write defaults values for it, but that's another topic)

(I guess that) tune2fs do not modify a property of the filesystem (it last argument), but set somewhere a bunch of settings which will be readed during boot-time by (which?) application, which will trigger fsck(if it's time to) passing to it those settings. (which can be different if you change them, but ... U cannot do so during boot-time, ergo, have to be 'written somewhere')
so, the last argument of tune2fs(according your examples, of course) is the filesystem over where to excecute fsck, rather than what to modify. (hope to be clear)

what I want is to modify the -c option of tune2fs *without* over-writting the other settings.(as explained in my previous post)

at this time you could tell 'just run it with -c WHAT-YOU-WANT, and other settings won't be overwritted', and this would be fine..
... but now I want to know how its settings are preserved!!!
(I bet it should have one config file.. or really would understand how it works)

cheers

That's your error. It DOES modify the settings in the file system, and nowhere else. And after all, tuning /dev/hda1 is not different at all to chmoding /home/peter/foo.

These values are not read from a config file at boot up and re-set at boot time, they are stored on the same fs and they are used since the same very moment that the fs driver comes into scene, and not at a later stage.

Those settings are embedded on the fs, and as I said on my other post, they won't change unless you run tune2fs again to change them. So, once you used -c whatever you don't ever need to worry about it again. That value won't change, and it wouldn't make any sense at all if it changed to a default value after each power off, if you think about it.

Using -c shouldn't change anything else either.

I forgot about this one, there's a -l parameter that can show many fs settings, give it a try

this is new to me.
is there a proprety within the fs which holds the interval of programmed-checking? thought it would be external to the fs by itself.
-but justify the lack of a config file.

so, gonna use it at last ;-)

thanks 4 the explanation

Storing data that's important for the fs inside the fs would be an unnecessary pain. You would first need to load the fs driver, mount the block device, read the config file and then adjust everything or even remount it. So it makes sense storing it on the same fs structures where you can reach the info before the fs is mounted. That's just my logic though, I can't say what the ext2 developers thought when programming it.

If you are interested you should read about the "superblock", coolest superhero ever

http://sunsite.nus.sg/LDP/LDP/tlk/node97.html

so the whole thing moves in a 'lower level' than what I thought.
btw: I followed the superblock link, and there is it:

in my case, aside showing a similar warning message, the ext3 fs also triggers the fsck utility (which is what I wanted to control)
now it's done.

thanks again!

About fsck, you can control that as well using the sixth field on the relevant line in /etc/fstab (fstab has a man page as well). It controls in which order fs's are checked at init, if the field is zero then it's never checked. Not advisable though.