[sf-lug] mass copy of one file to multiple user accounts

Michael Paoli Michael.Paoli at cal.berkeley.edu
Fri Sep 5 05:00:36 PDT 2008

> Date: Tue, 2 Sep 2008 09:28:27 -0700
> From: "Christian Einfeldt" <einfeldt at gmail.com>
> Subject: [sf-lug] mass copy of one file to multiple user accounts
> To: "sf-lug at linuxmafia.com List" <sf-lug at linuxmafia.com>

Well, my $0.02 worth or so ... many other suggestions were already made
along this "thread".

I might suggest/comment:
o *copying* the file per target account would be rather/quite wasteful
   - particularly talking about larger file, and identical content, to
   every - or many - accounts.
o linking - hard or soft links - much more space efficient and
   generally more maintainable than the above, but generally has the
   problem that users would typically be able to write in their $HOME
   directories, and as long as they can do that, they can generally
   remove file (or link) placed there - or at minimum, rename it rather
   arbitrarily.  There are more esoteric means one could go to to
   prevent users from removing/renaming item(s) placed there, but that
   would likely just cause more problems and confusion for yourself
   and/or the next person that has to figure out what's going on there,
   and how to maintain (update/change/etc.) it.  Although one could have
   user $HOME directories, where users couldn't write (and thus not
   rename/remove items there) in their $HOME directories, that would
   generally introduce quite another set of problems - at least for most
   relatively typical usage (e.g. if one is trying to make a generally
   fairly useful environment for the user(s), rather than a much more
   restrictive, nailed down, and can't muck with much of anything,
   learn, experiment, etc. environment, one would typically have users
   normally able to write in their own $HOME directories).
o as was suggested by some other(s), placing the file where it can be
   served up (e.g. fileserver or webserver) is a rather generally good
   idea - it can be suitably protected, and (read) access opened up as
   widely as deemed appropriate.  A webserver might be the simplest
   solution (e.g. Apache, and locate the file appropriately, and give
   the students the URL - perhaps even (pre-)load it into the bookmarks
   for their browser(s).
o Among suggestions related to the above, since the file is
   (relatively) large (media file, not some teensy little text file),
   primary audience is quite local (school lab), and availability to
   that audience is much more important than serving the file up to the
   Internet at large (which could also be done, or be done separately,
   if desired), it would seem most logical to have it hosted on a system
   in the school lab (would be much more reliably available, reduce
   external bandwidth costs/congestion, avoid dependence upon external
   resources for availability/updates/maintenance/etc.  So, ... I'd
   basically advocate that - put it on a local Apache server (or other
   fileserver), and have the students access it that way.

Anyone have a (much) better idea given the (reasonably) presumed
objectives and design criteria?  (if so, please explain, including

> I am trying to copy one file, a test song, from one directory in my user's
> account on an LDAP network to multiple accounts on the same network.  I want
> to make sure that when the file arrives in each user's directory, they will
> be able to play it, but not change it.  The program that we are using is GNU
> Denemo, although that doesn't really matter.  This is a run-of-the-mill
> permissions question, except that we are talking about copying one file to
> probably 200 directories or so.

More information about the sf-lug mailing list