[UCLA-LUG] file uid stuff

[chris]

you could always do it with perl and a hash.  like the below.  i didn't
test this or anything, so i don't know if it'll work right.  if it
doesn't, it shouldn't take much to fix it.  it needs a file named
"uid_map" that contains an old to new uid mapping, one per line, space
separated.  and it only works on files and directories.  anyway. 

-chris

#!/usr/local/bin/perl -T

my %curowner = ();

$mount = $ARGV[0];
lstat($mount);
($mount =~ /^\// && -d _) || die "usage: $0 /path/to/mount/point\n";
&recurse($mount);

open(I,"<uid_map") || die "open(uid_map): $!";
while (<I>) {
  my ($old,$new) = split(/\s/);
  my (@files) = split(/\0/,$curowner{$old});
  delete $curowner{$old};
  chown $new, @files;
}
close I;

sub recurse {
  my ($mount) = @_;
  my @entries = ();
  my @v = ();
  my $done = 0;
  my $e = '';

  opendir I,"$mount" || return;   
  @entries = readdir(I) || return;
  foreach $e ( @entries ) {
    next if $e eq '.' || $e eq '..';
    (@v) = lstat ("$mount/$e");
    $curowner{$v[4]} .= "$e" . "\0" if -d _ || -f _;
    &recurse("$mount/$e") if -d _;
  }
  closedir I;
}



On Fri, 18 Feb 2000, Glenn Glazer wrote:

> Hi, Dimi.
> 
> You are right that this method is faster given the restriction that you
> impose, namely that the files all belong to one user.  However, I
> understood the question to be of larger scope, for example, chown all files
> of all users whose UID is in the 10000's (10[0-9][0-9][0-9]).  Then, your
> method would have to be repeated for each user, whereas my method just uses
> the regexp in the appropriate place.  Also, in some business contexts, the
> manager of the group owns the group files.  So, if you change managers you
> can grep on the group name instead of the user name (for this use the ls
> method, not the find method).
> 
> Also, for Justin if he is still listening: add -xdev as an argument to the
> find command.  This will keep you from wandering into the /dev directories
> by accident.  -type f is insufficient for this (though you will want to
> keep it for the other reasons.)
> 
> Best,
> 
> Glenn
> 
> P.S.  While thinking about this, I coined a new term of venery: a regexp of
> users. :)  -GMG
> 
> At 12:44 PM 2/17/00 -0800, you wrote:
> >This problem really got me to thinkin... :)
> >I would approach it like this:  In high likelihood, all the files under a
> >particular user's home directory are owned by him.  With this assumption,
> >one could do a recursive chown -R dimator.dimator /home/dimator/
> >
> >But, there exists the possibility that there are some files in my home
> >directory that I do not own.  Since these are the exception to the norm, I
> >would do a 'find'  for these few files, and hang on to them in a temp
> >file.  Then after I did the recursive chown above, I would deal with the
> >exceptions in the temp file accordingly, chown'ing each of these to its
> >appropriate uid/gid.
> >
> >This has the (small?) advantage of calling less chown's, because your
> >'find' forks chown on each file seperately, wherease I make one recursive
> >chown call (which I assume is cheaper to run) and then x (where x is the
> >number of non-dimator owned files in my path; x << total files under
> >/home/dimator) chown's on the exception files.
> >
> >hope all that is clear. :)
> >
> >Dimi
> >
> >
> >On Thu, 17 Feb 2000, Justin Boseant wrote:
> >
> >> anyone know anything you can us in if [ ... ] to check if the uid of a
> >> file matches a variable?   I'm trying to switch all the user ids on a
> >> bunch of disks to new ones and my current idea uses 'find ./ -user ...'
> >> for each disk and loops through each pair of old/new ids.  I know its
> >> going to be time consuming either way, but is it more efficient to go
> >> through case statements for each file or go through the file system for
> >> each case (i.e. recursion vs. iteration, sort of).  
> >> 
> >> Any input is greatly apreciated.
> >> 
> >> -justin
> >> 
> >> p.s. I like ispell, I just don't use it enough
> >> 
> >> 
> >> _______________________________________________
> >> UCLALUG Linux mailing list - Linux@linux.ucla.edu
> >> http://linux.ucla.edu/mailman/listinfo/linux
> >> 
> >
> >
> >_______________________________________________
> >UCLALUG Linux mailing list - Linux@linux.ucla.edu
> >http://linux.ucla.edu/mailman/listinfo/linux
> 
> 
> _______________________________________________
> UCLALUG Linux mailing list - Linux@linux.ucla.edu
> http://linux.ucla.edu/mailman/listinfo/linux
>