[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: [BusyBox] Another bug(?) in cp
From:       Matt Kraai <kraai () alumni ! carnegiemellon ! edu>
Date:       2001-04-30 10:45:22
[Download RAW message or body]

On Mon, Apr 30, 2001 at 08:52:33AM -0700, Brian Webb wrote:
> Matt,
> 
> I see that code that you're refering to that should be changing the
> permissions, but for some reason it doesn't seem to be working in all cases
> on my system.  The place that it is getting executed is from a script run as
> init (init=/sbin/restore_defaults on the boot line).  This is a script that
> copies files from the cramfs root partition to a jffs partition.
> 
> The script looks like:
> 
> #!/bin/sh
> echo "Doing device reset"
> /defaults/ramdisk
> /defaults/flashdisk
> echo "Hard reset the machine now."
> while `true`
> do
> X=1
> done
> #aka infinite loop
> #
> 
> 
> /defaults/ramdisk:
> 
> #!/bin/sh
>  
> echo Mounting ramfs
> mount -n -t ramfs none /ram
>  
> echo Making var and tmp directories
> mkdir /ram/var
> mkdir /ram/var/lib
> mkdir /ram/var/lock
> mkdir /ram/var/lock/subsys
> mkdir /ram/var/log
> mkdir /ram/var/run
> mkdir /ram/var/run/utmp
> mkdir /ram/tmp
> chmod a+rwx /ram/tmp
> 
> 
> /defaults/flashdisk:
> 
> #!/bin/sh
>  
> echo Erasing flashdisk
> /sbin/eraseall /dev/mtd0
>  
> echo Mounting flashdisk
> mount -n -t jffs /dev/mtdblock0 /flash
>  
> echo Copying defaults to flashdisk
> cp -a /defaults/* /flash
>  
> echo Setting up permissions on /home/default
> # NOTE: I am concerned about this following links,
> # but it appears that BusyBox chown/chgrp don't
> # support the -h flag.
> chown -R default /flash/home/default
> chgrp -R users /flash/home/default
> 
> 
> Used in this mode it doesn't set the permissions correctly unless I add the
> umask patch.  For reference, I tried booting into /bin/bash and running
> /sbin/restore_defaults with the same results.  If I do the copy on the
> command line it seems to work, although I haven't verified that the
> permissions are exactly correct.
> 
> Any ideas why it would work different in these situations?  I initially
> thought it was a umask problem because it acts differently depending on
> where it's run from, so the only meaningful difference I could think of is
> that the umask may be set differently somehow.

Hmm.  Could you please modify the script to run umask before the
cp, so that we can see what it is?  And if you could send in the
ls -l listing for a device whose permissions are not copied
correctly?  I'd really like to understand what is going wrong
before I commit your fix.

Matt



[prev in list] [next in list] [prev in thread] [next in thread]