On Friday, 8. December 2006 13:47, Janning Vygen wrote: > Am Freitag, 8. Dezember 2006 11:29 schrieben Sie: > > On Thursday, 7. December 2006 22:45, Michael Tautschnig wrote: > > > > > > - some -k/--keep option (which I'd rather call --keep-permissions :-) ) > > > to retain the permissions of the file which should be overwritten (BTW: > > > what should happen if there is no such file?) > > > > I'm not against the option, but in the an FAI context, IMHO one should now > > user:group:permission before overriding a file. If there are different > > from host to host, then either it's wrong or I better 'code' this exception > > in the installation scripts. <- IMHO of course. > > Why should i know the user:group:permission of a file like /etc/sudoers. I > know it is there i want to override it and want to keep the permissions of > the orignial file. to me, it sounds very naturally, just to copy the content > of a file and keep original permissions.
If a file permission get borked it will never be fixed by an softupdate. In the case that it's not root:root 644 it has in most cases a special reason. If the file is missing there noting to preserve, what to use then? would be nice if a softupdate fixes it with right protections. > > > - some way to return the number of files that were actually copied. > > > > That does not sound unix'ish IMHO. Why not the > > paths of the files copied are listed on stdout. Num is then just adding > > '| wc -l'. And stuff like: fcopy --whatever | while read file; do ... > > are still possible. > > your absolutely right and i already wrote it this way, but i did use a > different format fcopy already uses: > > print "fcopy: copied $sourcefile to $destfile\n" ; that also okay. grep of sed can be used to transform > > i tried to use exit code, too: > > exit code is 0: if one or more files were changed (content or permissions) > and no errors occured > exit code is 1: if no files were changed (content nor permissions) and no > warnings or errors occured > exit code is 2: warnings or errors occured plus description of exit code 1 > exit code is 3: warnings or errors occured plus description of exit code 1 > exit code is 4: on all other conditions (show Usage etc.) > > this way you can say > > fcopy ... /etc/postgresql && /etc/init.d/postgresql restart || exit 1; > > What do you think about using exit codes? First i sort it's not unix like, > but > diff does like this, too. Add $? to your prompt and you'll see that much more apps do it like this ;) So both methods can coexists with file list turned on (or off) with a file an option. > > Philosophical: I favour postinst scripts for all this, i.e. event based > > programming ;) When using FAI the first time the split of data below > > files and scripts using then scattered over the rest of fai/config > > was very hard to follow. Now I use fcopy recursive once and logic is > > in postinst files. And if something is missing I would first think > > about adding another event script like postinst and filemode. > > but if you have more than two (or more) config files for a daemon you need > two > (or more) postinst scripts which reloads the daemon. And the daemon is > reloaded twice and maybe even before the second file is copied which might > even include a security hole. Because the daemon is restarted with only one > file changed, then copying the second file before restarting again. i don't > like restarting a half-configured daemon. Yeah, that's right. I didn't run into this yet (or didn't realize ;) I _assume_ I would have added a cfggroup.<desc>/ tree with the correlated files in it and used fcopy -r ... && <desc>-postinst construct like you. When it happened more often: groups/<desc>.{postinst,.d/,...} plus a little wrapper script, that loops, calls fcopy -r and the scripts. Achim > > kind regards > janning > > -- To me vi is Zen. To use vi is to practice zen. Every command is a koan. Profound to the user, unintelligible to the uninitiated. You discover truth everytime you use it. -- [EMAIL PROTECTED]