Message ID | 4F2125D6.2020505@tvdr.de |
---|---|
State | New |
Headers |
Received: from mail.tu-berlin.de ([130.149.7.33]) by www.linuxtv.org with esmtp (Exim 4.72) (envelope-from <Klaus.Schmidinger@tvdr.de>) id 1RqMEo-0008Fb-Te for vdr@linuxtv.org; Thu, 26 Jan 2012 11:07:27 +0100 X-tubIT-Incoming-IP: 188.40.50.18 Received: from racoon.tvdr.de ([188.40.50.18]) by mail.tu-berlin.de (exim-4.75/mailfrontend-2) with esmtps [TLSv1:AES256-SHA:256] for <vdr@linuxtv.org> id 1RqMEo-0000qY-I0; Thu, 26 Jan 2012 11:07:26 +0100 Received: from dolphin.tvdr.de (dolphin.tvdr.de [192.168.100.2]) by racoon.tvdr.de (8.14.3/8.14.3) with ESMTP id q0QA7e5W016897 for <vdr@linuxtv.org>; Thu, 26 Jan 2012 11:07:40 +0100 Received: from [192.168.100.10] (hawk.tvdr.de [192.168.100.10]) by dolphin.tvdr.de (8.14.4/8.14.4) with ESMTP id q0QA7I4N025528 for <vdr@linuxtv.org>; Thu, 26 Jan 2012 11:07:20 +0100 Message-ID: <4F2125D6.2020505@tvdr.de> Date: Thu, 26 Jan 2012 11:07:18 +0100 From: Klaus Schmidinger <Klaus.Schmidinger@tvdr.de> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111101 SUSE/3.1.16 Thunderbird/3.1.16 MIME-Version: 1.0 To: vdr@linuxtv.org References: <CAD9BhHuM+2T7MQoCKF2cuzOh8Rv5YdnhNzSqDQh0zaSNTE2EJg@mail.gmail.com> <4F1FCB6C.4000604@tvdr.de> <201201251411.48859@orion.escape-edv.de> In-Reply-To: <201201251411.48859@orion.escape-edv.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (racoon.tvdr.de [188.40.50.18]); Thu, 26 Jan 2012 11:07:40 +0100 (CET) X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.1.26.95118 X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' MSGID_ADDED_BY_MTA 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1600_1699 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_MAILTO 0, __URI_NS , __USER_AGENT 0' X-LSpam-Score: -1.9 (-) X-LSpam-Report: No, score=-1.9 required=5.0 tests=BAYES_00=-1.9 autolearn=ham Subject: Re: [vdr] vdr 1.7.23: patch for handling symlinks in recordings directory as earlier X-BeenThere: vdr@linuxtv.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: VDR Mailing List <vdr@linuxtv.org> List-Id: VDR Mailing List <vdr.linuxtv.org> List-Unsubscribe: <http://www.linuxtv.org/cgi-bin/mailman/options/vdr>, <mailto:vdr-request@linuxtv.org?subject=unsubscribe> List-Archive: <http://www.linuxtv.org/pipermail/vdr> List-Post: <mailto:vdr@linuxtv.org> List-Help: <mailto:vdr-request@linuxtv.org?subject=help> List-Subscribe: <http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>, <mailto:vdr-request@linuxtv.org?subject=subscribe> X-List-Received-Date: Thu, 26 Jan 2012 10:07:27 -0000 Status: O X-Status: X-Keywords: X-UID: 25655 |
Commit Message
Klaus Schmidinger
Jan. 26, 2012, 10:07 a.m. UTC
On 25.01.2012 14:11, Oliver Endriss wrote: > On Wednesday 25 January 2012 10:29:16 Klaus Schmidinger wrote: >> On 17.01.2012 14:26, sundararaj reel wrote: >>> Hi, >>> >>> I am attaching a patch for vdr 1.7.23 for the problem described here: >>> http://www.vdr-portal.de/board1-news/board2-vdr-news/p1047199-announce-vdr-developer-version-1-7-23/#post1047199 >>> >>> There appears to be a problem in listing recordings due to a bug fix >>> in vdr 1.7.23. "Fixed handling symbolic links in >>> cRecordings::ScanVideoDir()" >>> >>> The attached patch just disables the translation of symbolic links to >>> "real" paths. So that all recordings appear to be under the same >>> (recordings) directory tree, as it was earlier. >>> >>> Please reply with your results. >> >> Can somebody who has actually this use case please confirm >> whether this patch fixes the problem? > > Confirmed. > > Without this patch, symbolic links are not displayed > correctly on my machine. > > Oliver Thanks. I believe the second call to stat() is now superfluous. Can you please confirm that the following patch still works as expected? Klaus
Comments
On Thursday 26 January 2012 11:07:18 Klaus Schmidinger wrote: > On 25.01.2012 14:11, Oliver Endriss wrote: > > On Wednesday 25 January 2012 10:29:16 Klaus Schmidinger wrote: > >> On 17.01.2012 14:26, sundararaj reel wrote: > >>> Hi, > >>> > >>> I am attaching a patch for vdr 1.7.23 for the problem described here: > >>> http://www.vdr-portal.de/board1-news/board2-vdr-news/p1047199-announce-vdr-developer-version-1-7-23/#post1047199 > >>> > >>> There appears to be a problem in listing recordings due to a bug fix > >>> in vdr 1.7.23. "Fixed handling symbolic links in > >>> cRecordings::ScanVideoDir()" > >>> > >>> The attached patch just disables the translation of symbolic links to > >>> "real" paths. So that all recordings appear to be under the same > >>> (recordings) directory tree, as it was earlier. > >>> > >>> Please reply with your results. > >> > >> Can somebody who has actually this use case please confirm > >> whether this patch fixes the problem? > > > > Confirmed. > > > > Without this patch, symbolic links are not displayed > > correctly on my machine. > > > > Oliver > > Thanks. > > I believe the second call to stat() is now superfluous. > Can you please confirm that the following patch still works > as expected? > > --- recording.c 2012/01/25 09:32:39 2.45 > +++ recording.c 2012/01/26 10:02:29 > @@ -1120,11 +1120,6 @@ > continue; > } > Link = 1; > - buffer = ReadLink(buffer); > - if (!*buffer) > - continue; > - if (stat(buffer, &st) != 0) > - continue; > } > if (S_ISDIR(st.st_mode)) { > if (endswith(buffer, deleted ? DELEXT : RECEXT)) { Yes, it does not make any difference here. CU Oliver
On 01/27/2012 01:04 PM, Oliver Endriss wrote: > On Thursday 26 January 2012 11:07:18 Klaus Schmidinger wrote: >> On 25.01.2012 14:11, Oliver Endriss wrote: >>> On Wednesday 25 January 2012 10:29:16 Klaus Schmidinger wrote: >>>> On 17.01.2012 14:26, sundararaj reel wrote: >>>>> Hi, >>>>> >>>>> I am attaching a patch for vdr 1.7.23 for the problem described here: >>>>> http://www.vdr-portal.de/board1-news/board2-vdr-news/p1047199-announce-vdr-developer-version-1-7-23/#post1047199 >>>>> >>>>> There appears to be a problem in listing recordings due to a bug fix >>>>> in vdr 1.7.23. "Fixed handling symbolic links in >>>>> cRecordings::ScanVideoDir()" >>>>> >>>>> The attached patch just disables the translation of symbolic links to >>>>> "real" paths. So that all recordings appear to be under the same >>>>> (recordings) directory tree, as it was earlier. >>>>> >>>>> Please reply with your results. >>>> >>>> Can somebody who has actually this use case please confirm >>>> whether this patch fixes the problem? >>> >>> Confirmed. >>> >>> Without this patch, symbolic links are not displayed >>> correctly on my machine. >>> >>> Oliver >> >> Thanks. >> >> I believe the second call to stat() is now superfluous. >> Can you please confirm that the following patch still works >> as expected? >> >> --- recording.c 2012/01/25 09:32:39 2.45 >> +++ recording.c 2012/01/26 10:02:29 >> @@ -1120,11 +1120,6 @@ >> continue; >> }sundararaj reel >> Link = 1; >> - buffer = ReadLink(buffer); >> - if (!*buffer) >> - continue; >> - if (stat(buffer,&st) != 0) >> - continue; >> } >> if (S_ISDIR(st.st_mode)) { >> if (endswith(buffer, deleted ? DELEXT : RECEXT)) { > > Yes, it does not make any difference here. Well, with this patch, symbolic links are not displayed at all on my VDR machine, whereas with sundararaj reel's fix they are displayed correctly. Cheers, Lucian
--- recording.c 2012/01/25 09:32:39 2.45 +++ recording.c 2012/01/26 10:02:29 @@ -1120,11 +1120,6 @@ continue; } Link = 1; - buffer = ReadLink(buffer); - if (!*buffer) - continue; - if (stat(buffer, &st) != 0) - continue; } if (S_ISDIR(st.st_mode)) { if (endswith(buffer, deleted ? DELEXT : RECEXT)) {