Enhancement request: Simplify adding files to root and wrapper

[MAnantharaman]

While I have been able to make the changes I needed to my FB 7490 with modfs I had a couple of extra iterations because changes I wanted to make to the root and wrapper fs were not included in one of the two filesystems - because of my own carelessness in updating the binaries archive or copying to a rw-remounted wrapper. So I suggest:

• Let modscript copy_binaries copy a correspondingly named directory rather than insisting on an archive. See attached diff.

• Let modfs also copy to wrapper. I saw that you there are some hooks (ADD_TO_WRAPPER) to do this - which I build on for a q-n-d solution (see diff) but I am sure you could make it more robust and versatile.

Regards, Martin

EDIT: I am deeply ashamed that I initially attached a patchbefore final testing - but now it should be OK ... git.diff.2.gz

[PeterPawn]

The "copy_binaries" script is another example, how to build an own (quick&dirty) "modscript" - iirc, it doesn't check any precondition or the results of its modifications. Every user is encouraged to build his own script files for own modifications - if he/she thinks, that other people could find them useful, he/she could publish them in the IPPF thread (or in a new one there, if the author isn't able to speak, write, read in German). This solely "example" character of some "modscripts" is mentioned multiple times in the "main" IPPF thread.

The remaining fixed path "add_to_wrapper" was a mistake - I've missed it while converting my internal version to the public one. Thanks for the hint - the line was changed. I can't see any (real) difference between copying a directory structure with "cp -a" and using a "tar pipe". If you can explain any important difference between these approaches, I'd like to read this explanation.

Only an extra-large command line from "globbing" with the asterisk in the source path could lead to a problem ... as long as the command is intended to copy to the wrapper partition, the source should only contain some shorter directory names and (under some circumstances) the names of some "custom images". A resulting command line, which will bust the limits of the system, should not be expected here.

My recommendation to each user, who regularly uses "modfs" to update his device to a newer version of FRITZ!OS, is: Create your own directory for "modfs" under the NAS root directory and move the downloaded "modfs" version into this one, add your own scripts and create a "wrapper" script to call "modfs" with the needed environment settings - starting with "MODFS_DEBUG" (not needed any longer, the default value was changed meanwhile) and "ADD_TO_WRAPPER".

In the future I hope I'm able to provide an additional script, which checks the "modfs" version on GitHub and my server against the locally stored version and shows an option to "auto update" to the newest version prior to using "modfs".

As long as this doesn't exist, you can/should check (or get) the version from the server and overwrite existing files with newer ones from the server. That's one reason, why there's no "custom_modscripts" template in the archive from my server and no further examples (beside the description in the IPPF thread), how to use the "ADD_TO_WRAPPER" option.

My own "wrapper" simply looks like this:

#! /bin/sh
export ADD_TO_WRAPPER=add_to_wrapper
export MODFS_DEBUG_SHELL=1
./modfs update $1

[MAnantharaman]

Thanks, I stashed my changes and updated to git master. Two comments:

1. I suggested the tar-pipeline because IMHO it is the only safe way of integrating a directory in another including dot-files which are missed by globbing. But I do not need that for the moment, because ...
2. My main reason for changing /wrapper is to a) enable logging there (so I need a var/log) from some custom rc-scripts and b) place updated rc-scripts there (so I need etc/init.d). As an example attached is my heavily customized rc.S

I adopted your suggestion to have a wrapper for modfs - but I set MODFS_DEBUG (and extract log with showshringbuf after modfs) - as I could not understand what MODFS_DEBUG_SHELL really does ...

Regards, Martin rc.zip

[PeterPawn]

Using "cp -a" should include "dot files" (and "dot directories") into its recursion ... it avoids the second process needed to unpack the piped archive. If you want to exclude some files from being copied, such a tar pipe may be useful (with "exclude" option(s)).

Ignoring "dot directories" (and as a drawback "dot files" too) on the first stage (directly in the "ADD_TO_WRAPPER" directory, where globbing is active in my version with "cp -a $ADD_TO_WRAPPER/*") is intentional ... if my (currently hidden/ignored) ".git" directory would be included here, that's a really bad idea. Using "cp -a" without globbing here (cp -a $ADD_TO_WRAPPER) would include the whole version management directories for this (additional private) repository ... and "tar" would do the same (at least, I think so) and it would need additional steps to prevent this behavior.

MODFS_DEBUG_SHELL=1 calls each "modscript" and all other "external" shell scripts (from bin/scripts) with the "-x" option and creates a file in /var/tmp (with a fixed name) from their STDERR descriptors. It may be useful to debug own "modscripts" (screen output isn't cluttered anymore) ... but it's an option with "overall effect" (all scripts or none will be called this way).

The usual way to debug (specifying options in the SheBang line) does not work for "modscripts" (but "set -x" does), 'cause the scripts are called with an explicit shell name as command (and some environment additions) to ensure the right "ash" version from the embedded BusyBox binary.