install-log-devel — install-log developers' list

Re: [ID] # Old # and # Del #

[James R. <jr...@fu...>]

On Sat, Jul 28, 2001 at 02:48:09AM -0500, Andy Goth wrote:
> I added checking for old files and deleted files, as well as support for an 
> editor.  (OOPS!  I forgot to pass the filename to the editor... one moment, 
> please...)  Okay, that's fixed.
> 
> Check out the TODO list in install-log.c.  For proc_list, I'm considering 
> passing a va_list to the function.  What do you think?  Would that be too 
> clumsy?

Sounds ok to me. I'm quite rusty on va_lists, so you're probably better
qualified to call this one :)

> Please test it for me.  Use the --root option so that you don't clobber your 
> system-wide install-log database.  Pretend to install a package (just touch 
> three files, really), and then delete one, touch one, and leave the third one 
> alone, and finally run install-log --force with the same package name.  Read 
> the database and see if it worked.

I've added some error checking to the opendir function in find_newer, as
otherwise if people make a mistake in typing in the includes, they just get a
segmentation fault.

The read_db function work ok, once I put in the right headers for stat, and
tidied out a few other bugs (like "if (db_file = NULL) fail...", nice to know
the classic "= not ==" trips up other people than me :).

I also discovered that stat may need a proper buffer to point to if the file
exists - stat(filename, NULL) flung up some segmentation faults when it found
the file (probably trying to access NULL->st_mtime or something) until I gave
it a proper buffer. I wonder if there's a better function for telling if files
exist...

Oh, and I added a strip_end_newline() into util.c for reasons you can probably
guess :), and changed add_old_and_del_file to take into account the root.

-- 
James Reeves (Shade)
http://arevol.envy.nu/

[ID] # Old # and # Del #

[Andy G. <unu...@op...>]

I added checking for old files and deleted files, as well as support for an 
editor.  (OOPS!  I forgot to pass the filename to the editor... one moment, 
please...)  Okay, that's fixed.

Check out the TODO list in install-log.c.  For proc_list, I'm considering 
passing a va_list to the function.  What do you think?  Would that be too 
clumsy?

Please test it for me.  Use the --root option so that you don't clobber your 
system-wide install-log database.  Pretend to install a package (just touch 
three files, really), and then delete one, touch one, and leave the third one 
alone, and finally run install-log --force with the same package name.  Read 
the database and see if it worked.
-- 
Andy Goth  |  unu...@op...  |  http://sevatech.com/~andy/

[ID] Much, much more work

[Andy G. <unu...@op...>]

Chrooting works now.  (But cvs is down!!)

Linked lists have been redone.  Now the globals aren't List*'s.  They're just 
Lists.  Some of the linked list functions have been made static.  And 
config.c and logger.c have been modified to work with List*'s rather than 
List**'s.  I like it better this way, actually.  Be sure to read the new 
install-log.h to get an idea how much things have changed.

One thing--install-log.rc now reads /etc/install-log.rc (and 
ROOT/etc/install-log.rc, where ROOT is the parameter to --root)

Try this...

cd ~
mkdir test
mkdir test/etc
echo > test/etc/install-log.rc << EOF
INCLUDE=/usr
EXCLUDE=/usr/d
LOGDIR=/var
EOF
mkdir test/var
touch var/.timestamp
mkdir test/{usr/a,usr/b,usr/c,usr/d}
touch test/usr/{file,a/file,b/file,c/file1,c/file2,d/file}
PATH/install-log --root=test --verbosity=4 test-package

(where PATH is the path to install-log)
-- 
Andy Goth  |  unu...@op...  |  http://sevatech.com/~andy/

[ID] Harmless (?) bug

[Andy G. <unu...@op...>]

One harmless bug I see is the case of --exclude="".  For this, install-log 
will generate a list of *one* entry, a zero-length string.  But this is okay 
because no exclude search will match it.

Should I go through the trouble of culling all zero-length strings from 
include and exclude?

-- 
Andy Goth  |  unu...@op...  |  http://sevatech.com/~andy/

[ID] chroot quandary

[Andy G. <unu...@op...>]

First, I removed the pre-chroot option, because the root option is all that's 
necessary.  (I should make root default to ${LFS} if set, otherwise to "/".)  
But that's not the issue.

The issue is configuration parsing.
(1) Defaults built into executable
(2) Configuration file
(3) Command line

This way stuff can be overridden on the command line.  But!  What if the user 
wants to use the --root=/mnt/chroot option?  /mnt/chroot/etc/install-log.rc 
should be scanned, right?  Wouldn't that override the command line options, 
possibly including --root?  This is screwed up.  And what if the new 
configuration file sets root to something else?  Should install-log check for 
a configuration file in the new location as well?  And what if the new 
location's configuration file points back to the old one?

Uhm, I'm confused.  The only solution I can think of is adding an internal 
priority counter to configuration settings.  Initially it's zero.  When set 
from the configuration file, it's set to one.  When set from the command 
line, it's two.  If an attempt is made to set an option with a higher 
priority (i.e. overriding a command line option from the configuration file 
[when scanned the second time]), nothing happens.

Furthermore, the ROOT entry cannot be set from the configuration file.  This 
removes the possibility of scanning more than two configuration files and the 
possibility of getting into an infinite loop (with two pointing at each 
other).

I'll try implementing this.  If you see anything that needs to be fixed in 
this scheme, share, and we'll go back to the old version and do it Right.

-- 
Andy Goth  |  unu...@op...  |  http://sevatech.com/~andy/

Re: [ID] Much work

[Andy G. <unu...@op...>]

On Friday, July 27, 2001 5:41, you wrote:
> On Fri, Jul 27, 2001 at 12:35:38PM -0500, Andy Goth wrote:
> > It should be.  The only issue is that the dir_paste function doesn't look
> > very efficient.  It would be far faster if it didn't have to allocate a
> > buffer every time.  Any ideas?  Is there a MAX_PATH_LENGTH define
> > somewhere?
>
> PATH_MAX, or MAXPATHLEN in BSD. The realpath manpath contains a useful code
> fragment, which looks like it'll do the job, but you'll have to read up on
> the pathconf function:
> Will reply to rest of email in the morning :)

It doesn't matter--I converted dir_paste to work two ways.  If the last two 
parameters are NULL, then it's like before.  If the last two parameters point 
to buffers, then they're reused.  It works fine, and it's probably faster.

-- 
Andy Goth  |  unu...@op...  |  http://sevatech.com/~andy/

Re: [ID] Much work

[James R. <jr...@fu...>]

On Fri, Jul 27, 2001 at 12:35:38PM -0500, Andy Goth wrote:
> It should be.  The only issue is that the dir_paste function doesn't look 
> very efficient.  It would be far faster if it didn't have to allocate a 
> buffer every time.  Any ideas?  Is there a MAX_PATH_LENGTH define somewhere?

PATH_MAX, or MAXPATHLEN in BSD. The realpath manpath contains a useful code
fragment, which looks like it'll do the job, but you'll have to read up on the
pathconf function:

#ifdef PATH_MAX
	path_max = PATH_MAX;
#else
	path_max = pathconf (path, _PC_PATH_MAX);
	if (path_max <= 0)
		path_max = 4096;
#endif

Will reply to rest of email in the morning :)

-- 
James Reeves (Shade)
http://arevol.envy.nu/

Re: [ID] Much work

[Andy G. <unu...@op...>]

> > Hmm, what all did I do?  Mostly, I shortened the stuff you had written to
> > do the same thing in less lines of code.  In the process I actually made
> > it clearer, so many unnecessary comments were removed.
>
> Last job I was in, they insisted on commenting that much, and it seems to
> have become a bit of a habit; still, I suppose it was a little over the top
> :) - a more function based approach would have probably been better.

Comments are a sore issue in the world today.  Businesses and schools 
(probably schools MUCH, MUCH more than businesses) demand an excess.  But I 
believe that the code should be written to speak for itself, so that someone 
who doesn't exactly know the language can still figure it out.

if (list_has_string(list, cwd)) report(2, "excluding %s", cwd);

This line is pretty straightforward.  It manages to have several functional 
comments, comments that get compiled in.  "if list has string" is like a 
sentence, and the second parameter to report finishes the sentence, "if list 
has string, then exclude cwd, whatever the hell cwd means."

> > Just try and tell me with a straight face that this piece of code needs
> > more comments:
>
> <snip>
>
> Ok, ok. My main fault seems to be that I don't uses as many functions as I
> should do.

Use functions to eliminate repeated code.  Code written once probably 
shouldn't go in a function, unless the function the code was written into was 
already too long.  Code written twice becomes a very strong candidate.  Code 
written three times should be a compiler error. ;^)

> > You might notice from the above code that I managed to remove the chdirs
> > from your logger code.  Instead it calculates the long filename for
> > everything, using a dir_paste function I wrote (returns dir + "/" +
> > filename).  I put this function in util.c, along with some other stuff
> > that used to be in install-log.c.  I removed list.h while I was at it,
> > and I added reporting with multiple verbosity levels.  In the above
> > example, the user can get a list of every directory scanned by using
> > --verbosity=3.
>
> Hmmm. But is the long filename apporach any more efficient than the
> chdir/getcwd method I used?

It should be.  The only issue is that the dir_paste function doesn't look 
very efficient.  It would be far faster if it didn't have to allocate a 
buffer every time.  Any ideas?  Is there a MAX_PATH_LENGTH define somewhere?

> When I first thought about it I was going to
> use long filenames, but decided on chdirs because I figured let the OS
> worry about the pathname, and since chdir and getcwd must be fairly
> low-level, it probably wouldn't slow down find_newer much, if at all.

But then you'd need to call getcwd to get something suitable for looking 
through exclude for, and that precludes excluding individual files or 
checking for exclusion before calling another invocation of find_newer.

> Plus it meant that I didn't have to fiddle about with allocating memory for
> the long filenames (not too much anyway). Still, there can't be much
> between our two approaches to this problem.

I'd rather make dir_paste like this:

void dir_paste(const char* dir, const char* file, char** buffer, int& length)

If strlen(dir) + strlen(file) + 2 > *length, then {reallocate buffer to be 
the right size plus maybe sixteen extra, and change *length to reflect that 
size}.  Then it's business as normal, except that free doesn't need to be 
called nearly so often.

Shall I?
-- 
Andy Goth  |  unu...@op...  |  http://sevatech.com/~andy/

Re: [ID] database.c

[Andy G. <unu...@op...>]

On Friday, July 27, 2001 11:15, James Reeves wrote:
> On Thu, Jul 26, 2001 at 11:32:04PM -0500, Andy Goth wrote:
> > .. has been added.
> >
> > It contains the commit function which writes filelist to logdir/package. 
> > I haven't actually run it yet, but it looks right.
>
> Tested it by re-installing several tarball that I already logged with the
> old version; all contained the same files. Looks like the bare-bones are
> just about done :)

Cool.

> I'm probably going to add a few more lines into find_newer_wrapper to make
> the PRE_ROOT option work; I may not have time today though, so if it's
> still not done by the time you start working (the difference in timezones
> is quite useful in that respect), you're welcome to work on it :)

Yeah, I almost forgot about that option.  It's useful for building a new 
Linux installation because it works before the Linux installation is 
functional enough to support being chroot'ed to.  We definitely need to 
explain it in the man page, though.

Speaking of man pages, how does one write one of those things?  They're 
really nice to have, but I've never seen a guide on how to write one!

-- 
Andy Goth  |  unu...@op...  |  http://sevatech.com/~andy/

Re: [ID] Include list

[Andy G. <unu...@op...>]

> > /me smiles.  Yup, that's what I was thinking.  By the way, do you need me
> > to make a version of proc_list that can pass a va_list to the called
> > function?
>
> Your coding style seems to be much cleaner and function based than mine,

Thanks for the compliment.

> which is rather ad hoc :) - hopefully I can try and learn some good habits
> from this project.

Sure, take whatever you like from this project.  It's gpl, so you're 
certainly not forbidden from learning from it.

Heh, I'd hate to sign a nda, read some source code, find some good ideas (or 
stylings), and then pretend they didn't exist when trying to write my own 
code!  (I doubt ndas are *that* bad.)

> Recursion is ok when used in moderation, and I can't imagine descending
> down more than 10 dirs in an average filetree. I agree iteration would be
> better, memory wise, but would probably be more complex in a problem that
> is inherently recursive in nature. Besides, recursion looks nice & neat :)

Yeah, let's leave it.  It works the way it is, and the depth is rather 
shallow.

> > Okay, since you're working on the find_newer function, could you tell me
> > how you plan on handling symlinks to directories and (much harder?)
> > mounted directories?
>
> Symlinks should really be treated as files.

Currently, you don't follow symlinks, I think.  You use lstat, so you should 
be able to see a symlink for what it really is.  But, will that ISDIR thing 
say that a symlinked directory is a directory?  Then maybe you'll still 
descend into it.  Hey, -v3 should help you to spot this!  Make a little 
directory in your ~ and create a couple subdirectories and some symlinks.  
Then say -i~/dir to scan it.  (I *think* the ~ will work...)

> If a install process puts them
> in, they should be listed in the logs ideally.

I believe that in install-log.sh I skipped listing directories.

> Treating them as directories
> opens the way for infinite loops, and besides, if symlinks were followed
> you'd be logging the same thing twice, as the hardlink should surfice.

Surfice?  Made-up word?

> On the other hand, theres the problem with includes and excludes; if say,
> you had a symlink /usr/src/linux -> /usr/src/linux-2.4.7, and an exclude to
> ignore /linux-2.4.7 only, then ./linux would probably have to be ignored as
> well - no problem, if we're not follwing symlinks.

Check.

> Unfortunately what do you do if you want to exclude /usr/src/linux? Ideally
> the program would have to check if it had already been into the symlinked
> dir, and make a decision on that, or is this going too far?

This would be hard to code.  If it finds the excluded symlink first, it might 
be able to note that it skip what it points to, but if things happen the 
other way around, install-log can't possibly work as expected.  So let's 
slate this as a version 12 feature.

> Should we
> restrict includes/excludes to real directories only?

Sort of.  When symlinks are listed in exclude, they'll just get skipped.

Oh, forgot to tell you, the way I have find_newer written, it should be able 
to exclude individual files.  It checks exclude for every file, not just 
every invocation of find_newer (like you had it), so things may be slower, 
but on the other hand exclude lists don't get too long when there's an 
include list. ;^)  I haven't played with this side effect yet, though, so 
that's your job.

> That seems like the
> best way to me, although I could have missed something. What do you think?

*poot*

> > We could just assume (or require) that the user doesn't mount any
> > directories within the scope of install-log's searches.  There's not much
> > use for screwing with /usr or /opt or /lib in this way, but maybe I just
> > don't know enough about it.
>
> That assumption should be ok for now.

It's the install-log.sh assumption, and it hasn't failed yet.

> I don't think it's possible to create
> an infinite loop, as it only applies to one dir. When I tried mounting my
> home dir on a directory inside itself, it only went down one level; there
> was a /home/james/jim/jim but not a /home/jame/jim/jim/jim. Mounts aren't
> carried onto the next level in other words.

Whoa, that's cool.

> As for repeated dirs, well, later we could always try looking in mtab to
> look for mount --binds (I assume they're listed?).

/mnt/old/mp3 /home/ftp/music.all none rw,bind 0 0
/mnt/old/mp3 /music none rw,bind 0 0

This means that /home/ftp/music.all and /music should be automatically 
excluded, right?  Or maybe not.  I don't know...

> For the moment though,
> we're mimicing the old install-log, and no doubt that would get confused

Mmm, mime-icing...

> with mounted directories :) - and as you say, it seems quite unlikely
> anyone would do thing in /usr, /opt or whatever.

I haven't run across it yet.

> Woah! That was close! Almost did a rm -rf on ./jim, my mounted home dir.
> Must be this heat getting to me :)

Bindmounting?

-- 
Andy Goth  |  unu...@op...  |  http://sevatech.com/~andy/

Re: [ID] Much work

[James R. <jr...@fu...>]

On Thu, Jul 26, 2001 at 05:29:55PM -0500, Andy Goth wrote:
> I did a bunch of work with install-log, but for the moment I can't connect to 
> the cvs server (overloaded?), so hold off on editing until I can upload my 
> changes.

I was probably asleep when you made the changes anyway; different timezone :)

> Hmm, what all did I do?  Mostly, I shortened the stuff you had written to do 
> the same thing in less lines of code.  In the process I actually made it 
> clearer, so many unnecessary comments were removed.

Last job I was in, they insisted on commenting that much, and it seems to have
become a bit of a habit; still, I suppose it was a little over the top :) - a
more function based approach would have probably been better.
 
> Just try and tell me with a straight face that this piece of code needs more 
> comments:
<snip>

Ok, ok. My main fault seems to be that I don't uses as many functions as I
should do.

> You might notice from the above code that I managed to remove the chdirs from 
> your logger code.  Instead it calculates the long filename for everything, 
> using a dir_paste function I wrote (returns dir + "/" + filename).  I put 
> this function in util.c, along with some other stuff that used to be in 
> install-log.c.  I removed list.h while I was at it, and I added reporting 
> with multiple verbosity levels.  In the above example, the user can get a 
> list of every directory scanned by using --verbosity=3.

Hmmm. But is the long filename apporach any more efficient than the
chdir/getcwd method I used? When I first thought about it I was going to use
long filenames, but decided on chdirs because I figured let the OS worry about
the pathname, and since chdir and getcwd must be fairly low-level, it probably
wouldn't slow down find_newer much, if at all.

Plus it meant that I didn't have to fiddle about with allocating memory for the
long filenames (not too much anyway). Still, there can't be much between our
two approaches to this problem.

-- 
James Reeves (Shade)
http://arevol.envy.nu/

Re: [ID] database.c

[James R. <jr...@fu...>]

On Thu, Jul 26, 2001 at 11:32:04PM -0500, Andy Goth wrote:
> .. has been added.
> 
> It contains the commit function which writes filelist to logdir/package.  I 
> haven't actually run it yet, but it looks right.

Tested it by re-installing several tarball that I already logged with the old
version; all contained the same files. Looks like the bare-bones are just about
done :)

I'm probably going to add a few more lines into find_newer_wrapper to make the
PRE_ROOT option work; I may not have time today though, so if it's still not
done by the time you start working (the difference in timezones is quite useful
in that respect), you're welcome to work on it :)

-- 
James Reeves (Shade)
http://arevol.envy.nu/

Re: [ID] Include list

[James R. <jr...@fu...>]

(Heres hoping my smtp client handles this ok...)
On Thu, Jul 26, 2001 at 05:31:05PM -0500, Andy Goth wrote:
> > Hmmm, ok, I suppose it can be done as an iterative process; although if so,
> > it's just a matter of leaving find_newer alone and use a proc_list(include,
> > find_newer).
> 
> /me smiles.  Yup, that's what I was thinking.  By the way, do you need me to
> make a version of proc_list that can pass a va_list to the called function?

Your coding style seems to be much cleaner and function based than mine, which
is rather ad hoc :) - hopefully I can try and learn some good habits from this
project.

> > I think it was me trying to make it more difficult than it
> >  really was by trying to sort out the include list recursively in
> > find_newer, rather than treating it as something separate.
> 
> I'd rather find_newer not be recursive (to be nicer to the stack), but it's
> still the cleanest approach.  Many times, though, in the linked list code, I
> saw recursive ways but avoided them with just one extra line of code.  Maybe
> we'll find this.

Recursion is ok when used in moderation, and I can't imagine descending down
more than 10 dirs in an average filetree. I agree iteration would be better,
memory wise, but would probably be more complex in a problem that is inherently
recursive in nature. Besides, recursion looks nice & neat :)

> Okay, since you're working on the find_newer function, could you tell me how
> you plan on handling symlinks to directories and (much harder?) mounted
> directories?

Symlinks should really be treated as files. If a install process puts them in,
they should be listed in the logs ideally. Treating them as directories opens
the way for infinite loops, and besides, if symlinks were followed you'd be
logging the same thing twice, as the hardlink should surfice. 

On the other hand, theres the problem with includes and excludes; if say, you
had a symlink /usr/src/linux -> /usr/src/linux-2.4.7, and an exclude to ignore
/linux-2.4.7 only, then ./linux would probably have to be ignored as well - no
problem, if we're not follwing symlinks. 

Unfortunately what do you do if you want to exclude /usr/src/linux? Ideally the
program would have to check if it had already been into the symlinked dir, and
make a decision on that, or is this going too far?  Should we restrict
includes/excludes to real directories only?  That seems like the best way to
me, although I could have missed something. What do you think?

> By mounted directories, I am referring to the following 2.4 trick:
> 
> mount --bind /home/andy/music /home/ftp/pub/mp3
> 
> This'll make my music directory available in the ftp tree, even if the ftp
> client operates in a chroot jail and thus cannot have symlinks pointing to
> the outside world.  It's similar to hard-linking directories, I guess.
> 
> So, is it possible to create an infinite loop with this?  If not, then we
> might be okay, but the same file still might get listed twice (or more).  Say
> this happens, and then install-log tries to remove a package.  It'll delete
> the first occurrence of the file just fine, but when it tries to delete the
> second one it'll find that it's already gone.  This is different from hard
> links, where both links will need to be deleted.  What do we do?
> 
> We could just assume (or require) that the user doesn't mount any directories
> within the scope of install-log's searches.  There's not much use for
> screwing with /usr or /opt or /lib in this way, but maybe I just don't know
> enough about it.

That assumption should be ok for now. I don't think it's possible to create an
infinite loop, as it only applies to one dir. When I tried mounting my home dir
on a directory inside itself, it only went down one level; there was a
/home/james/jim/jim but not a /home/jame/jim/jim/jim. Mounts aren't carried
onto the next level in other words. 

As for repeated dirs, well, later we could always try looking in mtab to look
for mount --binds (I assume they're listed?). For the moment though, we're
mimicing the old install-log, and no doubt that would get confused with mounted
directories :) - and as you say, it seems quite unlikely anyone would do thing
in /usr, /opt or whatever.

Woah! That was close! Almost did a rm -rf on ./jim, my mounted home dir. Must
be this heat getting to me :)

-- 
James Reeves (Shade)
http://arevol.envy.nu/

[ID] database.c

[Andy G. <unu...@op...>]

... has been added.

It contains the commit function which writes filelist to logdir/package.  I 
haven't actually run it yet, but it looks right.

-- 
Andy Goth  |  unu...@op...  |  http://sevatech.com/~andy/

[ID] static

[Andy G. <unu...@op...>]

Oh, oops, forgot to mention it...

Declare variables and functions 'static' when they don't need to be touched 
outside of a single source file.  If a function (or variable!) isn't static, 
then declare it 'extern' in install-log.h so that other source files can more 
easily access it.

When you make a new variable or function, be sure to consider whether it's 
just a helper for this source file or if it's an interface to the other 
source files.  Don't export both find_all *and* find_newer, for instance.  
find_newer was really a helper function for find_all.  (And, in my version of 
logger.c, find_all actually calls a helper function which _then_ calls 
find_newer.)

-- 
Andy Goth  |  unu...@op...  |  http://sevatech.com/~andy/

[ID] Changes uploaded

[Andy G. <unu...@op...>]

!

Yay, the cvs server's up again.  And my changes are in effect.  Be sure to 
cvs update and look over what all I've done.  My last update has touched nine 
source files, added one, and removed one.  I personally don't like one commit 
changing a whole bunch of stuff, because it makes it a little harder to go 
back in versions, but I wasn't able to incrementally commit this time.

-- 
Andy Goth  |  unu...@op...  |  http://sevatech.com/~andy/

Re: [ID] Include list

[Andy G. <unu...@op...>]

> Hmmm, ok, I suppose it can be done as an iterative process; although if so,
> it's just a matter of leaving find_newer alone and use a proc_list(include,
> find_newer).

/me smiles.  Yup, that's what I was thinking.  By the way, do you need me to
make a version of proc_list that can pass a va_list to the called function?

> I think it was me trying to make it more difficult than it
>  really was by trying to sort out the include list recursively in
> find_newer, rather than treating it as something separate.

I'd rather find_newer not be recursive (to be nicer to the stack), but it's
still the cleanest approach.  Many times, though, in the linked list code, I
saw recursive ways but avoided them with just one extra line of code.  Maybe
we'll find this.

Okay, since you're working on the find_newer function, could you tell me how
you plan on handling symlinks to directories and (much harder?) mounted
directories?

By mounted directories, I am referring to the following 2.4 trick:

mount --bind /home/andy/music /home/ftp/pub/mp3

This'll make my music directory available in the ftp tree, even if the ftp
client operates in a chroot jail and thus cannot have symlinks pointing to
the outside world.  It's similar to hard-linking directories, I guess.

So, is it possible to create an infinite loop with this?  If not, then we
might be okay, but the same file still might get listed twice (or more).  Say
this happens, and then install-log tries to remove a package.  It'll delete
the first occurrence of the file just fine, but when it tries to delete the
second one it'll find that it's already gone.  This is different from hard
links, where both links will need to be deleted.  What do we do?

We could just assume (or require) that the user doesn't mount any directories
within the scope of install-log's searches.  There's not much use for
screwing with /usr or /opt or /lib in this way, but maybe I just don't know
enough about it.

-- 
Andy Goth  |  unu...@op...  |  http://sevatech.com/~andy/

[ID] Much work

[Andy G. <unu...@op...>]

I did a bunch of work with install-log, but for the moment I can't connect to 
the cvs server (overloaded?), so hold off on editing until I can upload my 
changes.

Hmm, what all did I do?  Mostly, I shortened the stuff you had written to do 
the same thing in less lines of code.  In the process I actually made it 
clearer, so many unnecessary comments were removed.

Just try and tell me with a straight face that this piece of code needs more 
comments:

		/* Process this directory entry */
		if (lstat(filename, &stat) == -1) {
			perror("lstat");	/* lstat failed, so skip file */
		} else if (list_has_string(exclude, filename)) {
			report(2, "Excluding %s\n", filename);
		} else if (S_ISDIR(stat.st_mode)) {
			report(3, "Descending into %s\n", filename);
			find_newer(filename);
		} else if (timestamp < stat.st_mtime) {
			report(4, "Adding %s\n", filename);
			add_node_with_string(&filenode, filename);
		}

See?

You might notice from the above code that I managed to remove the chdirs from 
your logger code.  Instead it calculates the long filename for everything, 
using a dir_paste function I wrote (returns dir + "/" + filename).  I put 
this function in util.c, along with some other stuff that used to be in 
install-log.c.  I removed list.h while I was at it, and I added reporting 
with multiple verbosity levels.  In the above example, the user can get a 
list of every directory scanned by using --verbosity=3.

-- 
Andy Goth  |  unu...@op...  |  http://sevatech.com/~andy/

Re: [ID] Include list

[Andy G. <unu...@op...>]

Subject: Re: [ID] Include list
Date: Thu, 26 Jul 2001 14:30:59 +0100
From: James Reeves <jr...@fu...>
To: Andy Goth <unu...@op...>

On Wed, Jul 25, 2001 at 09:06:20PM -0500, Andy Goth wrote:
> On Wednesday, July 25, 2001 12:32, you wrote:
> > After trying to implement the include list into the logger there may be a
> > few unforeseen problems with it. Firstly, there's the order in which the
> > excludes and includes are checked; in order for it to work, the
> > directories have to first be included (like /usr) and then more specific
> > directories excluded (like /usr/src). However this means that includes
> > are limited to the top level only, you can't, say, exclude /home but
> > include
> > /home/special, as excludes would override the includes.
>
> Aw, it can't be *that* hard!  Scan only what's listed in the include list,
> and stop at the items in the exclude list.

<snip>

Hmmm, ok, I suppose it can be done as an iterative process; although if so,
it's just a matter of leaving find_newer alone and use a proc_list(include,
find_newer). I think it was me trying to make it more difficult than it
 really was by trying to sort out the include list recursively in find_newer,
 rather than treating it as something separate.

..

Ok, done it. That was quite easy actually; that'll teach me to try at work
 out how to program something at 1am - thx for putting me right :)

--
James Reeves (Shade)
http://arevol.envy.nu/

Re: [ID] timestamp.c

[James R. <jr...@fu...>]

On Wed, Jul 25, 2001 at 11:40:41PM +0100, James Reeves wrote:
> On Wed, Jul 25, 2001 at 03:27:27PM -0500, Andy Goth wrote:
> > .. has been added.  Play with it some.
> 
> Practically the same as the one I quickly hacked up to test find_newer, except
> mine used chdir rather than specifying the whole path. Anyway, do you want me
> to do a "touch" func, or will you? If so, utime is the func you want:
> 
> #include <sys/types.h>
> #include <utime.h>
> #include <time.h>
> 
> struct utimbuf buf;
> buf.modtime = time(NULL);
> buf.actime = time(NULL);
> utime(filename, &buf);
> 
> That'll probably work :)

Yes, it does, but I've just re-read the manpage and discovered a simpler way:

#include <sys/types.h>
#include <utime.h>

utime(filename, NULL);

Much simpler :)

-- 
James Reeves (Shade)
http://arevol.envy.nu/

Re: [ID] timestamp.c

[James R. <jr...@fu...>]

On Wed, Jul 25, 2001 at 03:27:27PM -0500, Andy Goth wrote:
> .. has been added.  Play with it some.

Practically the same as the one I quickly hacked up to test find_newer, except
mine used chdir rather than specifying the whole path. Anyway, do you want me
to do a "touch" func, or will you? If so, utime is the func you want:

#include <sys/types.h>
#include <utime.h>
#include <time.h>

struct utimbuf buf;
buf.modtime = time(NULL);
buf.actime = time(NULL);
utime(filename, &buf);

That'll probably work :)

-- 
James Reeves (Shade)
http://arevol.envy.nu/

Re: [ID] timestamp.c

[James R. <jr...@fu...>]

On Wed, Jul 25, 2001 at 03:27:27PM -0500, Andy Goth wrote:
> .. has been added.  Play with it some.
> 
> Hey, do you want to convert find_newer to use the linked list exclude, or do 
> you want me to show you how (i.e. do it for you)?  And do you want me to fix 
> the tab stops?  I don't want to mess with logger.c--it's your file--without 
> your permission.  I mean, stomping on your work isn't productive!

Sorry it's been a while in answering - smtp was playing up :(

Anyway, ok, I'll download timestamp.c and look at that - I started writing a
bit of timestamp stuff, but it was only a few lines anyway. As for the
tab-stops - do you want them 8-space or what?

-- 
James Reeves (Shade)
http://arevol.envy.nu/

Re: [ID] Linked lists

[James R. <jr...@fu...>]

On Tue, Jul 24, 2001 at 07:03:28PM -0500, Andy Goth wrote:
> (Damn, I did it again.)
> 
> > logger.c... would you mind sticking to 80 columns?  That's pretty much
> > standard.
> 
> Maybe you *are* using 80 columns, but we have different tab stops.  I try to 
> stick to the Linux kernel source indentation and layout, so that means a tab 
> stop every eight characters.  That forces me to avoid nesting too deeply.  (I 
> still need to work on that one, though.)

It's more or less 80 columns; unfortunately gvim sometimes gives me a bit extra
without me knowing about it. I use a tab spacing of 3 myself, so no wonder it
looks a little stretched on your display :)

Should I try changing my tab size?
 
> > I'll read through and compile logger.c in a moment.  Thanks for writing it!
> 
> logger.c compiles just fine, here, but it never gets called.

Yep, I'm just adding a bit that'll call it, along with a get_timestamp
function.

-- 
James Reeves (Shade)
http://arevol.envy.nu/

[ID] Include list

[James R. <jr...@fu...>]

After trying to implement the include list into the logger there may be a few
unforeseen problems with it. Firstly, there's the order in which the excludes
and includes are checked; in order for it to work, the directories have to
first be included (like /usr) and then more specific directories excluded (like
/usr/src). However this means that includes are limited to the top level only,
you can't, say, exclude /home but include /home/special, as excludes would
override the includes. 

Also you get problems if you try to just include /home/special without
including /home; the program would have to go down the dir tree and ignore all
entrys in /home except /home/special, which tends to increase complexity (and
so slow down the program).

The easiest way to implement the includes then, would be to run find_newer on
each dir separately, like find_newer("/bin", timestamp), find_newer("/lib",
timestamp), but obviously in a loop. This may create confusion amongst the
users though; say a user wants to include /home/bin but not anything else in
home, he may try an --exclude=/home and an --include=/home/bin, which wouldn't
work normally. For it to function properly you would have to have to have a
program which figures out that he wants to exclude all directories in /home
_except_ for bin/ - and you can probably see how tricky this could become.

It might be easiest then, to just have an exclude list, as this is fast to
implement (if in dir that matches exclude, cd ..) and isn't that much more work
for the user. If we provide a sample rc file then the user's job would be even
easier.

Oh, and it'll be easier to program ;)

-- 
James Reeves (Shade)
http://arevol.envy.nu/

Re: [ID] realpath

[James R. <jr...@fu...>]

On Wed, Jul 25, 2001 at 01:08:16AM -0500, Andy Goth wrote:
> Found it!!
> 
> $ man realpath

That'll save some work then :)

-- 
James Reeves (Shade)
http://arevol.envy.nu/