On Tue, Mar 9, 2010 at 3:16 PM, Ionut Biru <[email protected]> wrote: > On 03/09/2010 10:43 PM, Ionut Biru wrote: >> >> On 03/09/2010 10:04 PM, Aaron Griffin wrote: >>> >>> On Tue, Mar 9, 2010 at 12:41 PM, Dan McGee<[email protected]> wrote: >>>> >>>> On Tue, Mar 9, 2010 at 12:23 PM, Ionut Biru<[email protected]> wrote: >>>>> >>>>> On 03/09/2010 08:22 PM, Loui Chang wrote: >>>>>> >>>>>> On Tue 09 Mar 2010 19:06 +0200, Ionut Biru wrote: >>>>>>> >>>>>>> can you change the permission of the file? >>>>>>> i really don't know why it has such a permission. I know that we have >>>>>>> a cron that fixes the permission but that package was upload >>>>>>> yesterday and still has it wrong. >>>>>>> >>>>>>> Can you check if the cron is running? >>>>>> >>>>>> Yeah it's running. >>>>>> >>>>>> The cron script only specifies g+w so it could still remain unreadable >>>>>> I'm not sure what the policy should be exactly, so maybe you can bring >>>>>> that up on the ML but I've made that file world readable. >>>>>> >>>>> >>>>> this is the second time when this happen and to be fair i don't know >>>>> why. >>>>> The cron has: >>>>> >>>>> /bin/chmod -R g+w $d/os/{any,i686,x86_64} >>>>> >>>>> maybe is better if we change it do chmod 664 by default? >>>> >>>> The cron job shouldn't do this; the dbscripts should, right? If we >>>> just got the permissions right there we wouldn't need the cron job at >>>> all actually. >>> >>> Yeah, the dbscripts actually DO cover this case. The cron job is there >>> because people sometimes manually move files around. >>> >>> Are people regularly manually moving files? If so it's important to >>> make sure you chmod the files for other users >> >> really don't know but the permission was 620 and i should ask what was >> the workflow. >> > > ok. so he has umask 077 and because we are using rsync the permission is > persistent. maybe we should fix dbscripts and install the package with the > right permission.
Patches welcome. :) -Dan
