[FFmpeg-devel] [PATCH] web: Copy FFmpeg Logo by Makefile instead of cronjob

[Michael Niedermayer]

On Tue, Apr 17, 2012 at 11:41:07AM +0200, Thilo Borgmann wrote:
> Am 16.04.12 23:57, schrieb Reimar Döffinger:
> > On 16 Apr 2012, at 23:43, Thilo Borgmann <thilo.borgmann at googlemail.com>
> > wrote:
> >> Am 16.04.12 21:51, schrieb Reimar Döffinger:
> >>> On 16 Apr 2012, at 17:36, Thilo Borgmann <thilo.borgmann at googlemail.com> 
> >>> wrote:
> >>>> Am 14.04.12 18:05, schrieb Reimar Döffinger:
> >>>>> On Sat, Apr 14, 2012 at 11:46:03AM +0200, Michael Niedermayer wrote:
> >>>>>> On Wed, Apr 11, 2012 at 12:50:34PM +0200, Thilo Borgmann wrote:
> >>>>>>>> this will update teh file even if it matches, this breaks
> >>>>>>>> caching of the logo
> >>>>>>> 
> >>>>>>> Updated Patch attached.
> >>>>>> 
> >>>>>> from a quick look, its ok maybe reimar can double check ?
> >>>>> 
> >>>>> I don't see any real issues with it. Though if you're pedantic
> >>>>> there's a questions whether "test -r" is the best condition, copying
> >>>>> over the file to my knowledge won't fix any permissions which is why
> >>>>> I went with -f originally. I don't think it really matters, when it
> >>>>> makes a different things are already seriously broken anyway and will
> >>>>> need manual intervention.
> >>>> 
> >>>> I don't really get it.
> >>>> 
> >>>> "test -r" or "test -f" - what does that have to do with fixing 
> >>>> permissions?
> >>> 
> >>> What is the point of overwriting the file when  the problem is that the
> >>> file exists but is not readable, when that will be the case afterward
> >>> still?
> >> 
> >>> That's why I chose -f since it avoids pointlessly copying, but as said I 
> >>> think it doesn't matter really.
> >> 
> >> I might misunderstand test, but -f would pointlessly copy if the file is
> >> not readable. -r would at least not do that but could still fail if the
> >> file is not writable. So if we check the file, we should have to check r&w
> >> permissions.
> > 
> > test -f will fail (and thus cause the copy) when the file is not a regular
> > file (so -e might be better). test -r will fail when the file is not
> > readable, including when it exists but does not have read permissions.
> > 
> >> What do you think about "cp -f" to retain permissions of the
> >> previous/initial file? Useful in my eyes if the git repo creates files with
> >> different permission than we want for the logo file.
> > 
> > I don't know where you got your understanding of the -f option from, but my
> > manpage certainly does not match it. If the file is writeable -f or not does
> > not make a difference, permissions remain unchanged. Only if write
> > permissions are missing does the behaviour differ: without -f it will fail,
> > with it will delete the file and potentially recreate it with new permissions
> > (I presume with the default permissions based on umask). 
> 
> cp seems to differ actually...
> https://developer.apple.com/library/mac/#documentation/Darwin/Reference/Manpages/man1/cp.1.html
> 
> However, patch applied.
> 
> -Thilo
> 

>  Makefile |   14 ++++++++++++--
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 47b04de93a2e972467f8f6b6a55e63ac3f570b88  0001-web-Let-the-Makefile-copy-the-website-logo-according.patch
> From 57ab223b421e83f75761bd7d77098bbf5fd5ea84 Mon Sep 17 00:00:00 2001
> From: Thilo Borgmann <thilo.borgmann at googlemail.com>
> Date: Tue, 17 Apr 2012 11:37:53 +0200
> Subject: [PATCH] web: Let the Makefile copy the website logo according to src/logik.

has the makefile been tested with all combinations of copy cases ?

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120419/37f0736e/attachment.asc>