From patchwork Mon Feb 13 09:43:51 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Klaus Schmidinger X-Patchwork-Id: 12927 Received: from mail.tu-berlin.de ([130.149.7.33]) by www.linuxtv.org with esmtp (Exim 4.72) (envelope-from ) id 1RwsRz-0004bO-Lg for vdr@linuxtv.org; Mon, 13 Feb 2012 10:44:00 +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-3) with esmtps [TLSv1:AES256-SHA:256] for id 1RwsRy-00050p-Ek; Mon, 13 Feb 2012 10:43:59 +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 q1D9iFYR030446 for ; Mon, 13 Feb 2012 10:44:15 +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 q1D9hpoA002361 for ; Mon, 13 Feb 2012 10:43:51 +0100 Message-ID: <4F38DB57.1000508@tvdr.de> Date: Mon, 13 Feb 2012 10:43:51 +0100 From: Klaus Schmidinger 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: <201201251411.48859@orion.escape-edv.de> <4F2125D6.2020505@tvdr.de> <201201271304.12550@orion.escape-edv.de> <4F383905.2080503@users.sourceforge.net> In-Reply-To: <4F383905.2080503@users.sourceforge.net> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (racoon.tvdr.de [188.40.50.18]); Mon, 13 Feb 2012 10:44:15 +0100 (CET) X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.2.13.93020 X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' MSGID_ADDED_BY_MTA 0.05, BODY_SIZE_3000_3999 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.1 (-) X-LSpam-Report: No, score=-1.1 required=5.0 tests=BAYES_00=-1.9, RDNS_NONE=0.793 autolearn=no 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 List-Id: VDR Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 09:44:00 -0000 Status: O X-Status: X-Keywords: X-UID: 25704 > 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 How did this "sundararaj reel" get in here? >>> 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. So what you're saying it that this... ---------------------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------------- ...doesn't? I find that hard to believe, because the only difference here is that the second version removes the stat() call, which is superfluous if 'buffer' is no longer modified. Klaus --- a/recording.c +++ b/recording.c @@ -1120,9 +1120,13 @@ void cRecordings::ScanVideoDir(const char *DirName, bool Foreground, int LinkLev continue; } Link = 1; +#if 0 + // do not resolve the symbolic links in paths to real path + // thereby keeping all the recordings under one directory buffer = ReadLink(buffer); if (!*buffer) continue; +#endif if (stat(buffer, &st) != 0) continue; } ---------------------------------------------------------------------------------------------- ...works, while this... ---------------------------------------------------------------------------------------------- --- 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)) {