Message ID | 4F38DB57.1000508@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 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 <vdr@linuxtv.org> 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 <vdr@linuxtv.org>; 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 <vdr@linuxtv.org>; 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 <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> <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> 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]); 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 <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: Mon, 13 Feb 2012 09:44:00 -0000 Status: O X-Status: X-Keywords: X-UID: 25704 |
Commit Message
Klaus Schmidinger
Feb. 13, 2012, 9:43 a.m. UTC
> 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
Comments
On 13.02.2012 10:43, Klaus Schmidinger wrote: >> 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: [...] >> 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... > > ---------------------------------------------------------------------------------------------- > > --- 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)) { > ---------------------------------------------------------------------------------------------- > > > ...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. Haven't really looked at the code, until now, and I also do not exactly know what the call to stat does and also didn't try to understand the whole picture now, but your patch does not simply remove just the call to stat, but also a *continue* statement from the *while* loop, this could have strong implications, so just please consider analyzing the issue with respect to that. Regards, Lucian
On 13.02.2012 11:44, Lucian Muresan wrote: > On 13.02.2012 10:43, Klaus Schmidinger wrote: >>> 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: > > [...] > >>> 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... >> >> ---------------------------------------------------------------------------------------------- >> >> --- 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)) { >> ---------------------------------------------------------------------------------------------- >> >> >> ...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. > > Haven't really looked at the code, until now, and I also do not exactly know what the call to stat does and also didn't try to understand the whole picture now, but your patch does not simply remove just the call to stat, but also a *continue* statement from the *while* loop, this could have strong > implications, so just please consider analyzing the issue with respect to that. The original code was ---------------------------------------------------------------------------------------------- if (stat(buffer, &st) == 0) { int Link = 0; if (S_ISLNK(st.st_mode)) { if (LinkLevel > MAX_LINK_LEVEL) { isyslog("max link level exceeded - not scanning %s", *buffer); continue; } Link = 1; buffer = ReadLink(buffer); if (!*buffer) continue; if (stat(buffer, &st) != 0) continue; } ... } ---------------------------------------------------------------------------------------------- After Sundararaj's patch it looked like this (just leaving out the lines that his '#if 0' disabled): ---------------------------------------------------------------------------------------------- if (stat(buffer, &st) == 0) { int Link = 0; if (S_ISLNK(st.st_mode)) { if (LinkLevel > MAX_LINK_LEVEL) { isyslog("max link level exceeded - not scanning %s", *buffer); continue; } if (stat(buffer, &st) != 0) continue; } ... } ---------------------------------------------------------------------------------------------- Reducing this to the stat() calls results in ---------------------------------------------------------------------------------------------- if (stat(buffer, &st) == 0) { ... if (stat(buffer, &st) != 0) continue; } ... } ---------------------------------------------------------------------------------------------- As you can see, 'buffer' is no longer modified between the two calls, so they will both return the same value. The code sequence is only entered if the first stat() call returns 0, so the second call will also return 0, and thus the 'continue' statement will never be executed. Klaus
On 13.02.2012 12:00, Klaus Schmidinger wrote: > On 13.02.2012 11:44, Lucian Muresan wrote: >> On 13.02.2012 10:43, Klaus Schmidinger wrote: >>>> 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: >> >> [...] >> >>>> 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... >>> >>> ---------------------------------------------------------------------------------------------- >>> >>> >>> --- 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)) { >>> ---------------------------------------------------------------------------------------------- >>> >>> >>> >>> ...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. >> >> Haven't really looked at the code, until now, and I also do not >> exactly know what the call to stat does and also didn't try to >> understand the whole picture now, but your patch does not simply >> remove just the call to stat, but also a *continue* statement from the >> *while* loop, this could have strong >> implications, so just please consider analyzing the issue with respect >> to that. > > The original code was > > ---------------------------------------------------------------------------------------------- > > if (stat(buffer, &st) == 0) { > int Link = 0; > if (S_ISLNK(st.st_mode)) { > if (LinkLevel > MAX_LINK_LEVEL) { > isyslog("max link level exceeded - not scanning %s", *buffer); > continue; > } > Link = 1; > buffer = ReadLink(buffer); > if (!*buffer) > continue; > if (stat(buffer, &st) != 0) > continue; > } > ... > } > ---------------------------------------------------------------------------------------------- > > > After Sundararaj's patch it looked like this (just leaving out the lines > that his '#if 0' disabled): > > ---------------------------------------------------------------------------------------------- > > if (stat(buffer, &st) == 0) { > int Link = 0; > if (S_ISLNK(st.st_mode)) { > if (LinkLevel > MAX_LINK_LEVEL) { > isyslog("max link level exceeded - not scanning %s", *buffer); > continue; > } > if (stat(buffer, &st) != 0) > continue; > } > ... > } > ---------------------------------------------------------------------------------------------- > > > Reducing this to the stat() calls results in > > ---------------------------------------------------------------------------------------------- > > if (stat(buffer, &st) == 0) { > ... > if (stat(buffer, &st) != 0) > continue; > } > ... > } > ---------------------------------------------------------------------------------------------- > > > As you can see, 'buffer' is no longer modified between the two calls, so > they > will both return the same value. The code sequence is only entered if > the first > stat() call returns 0, so the second call will also return 0, and thus the > 'continue' statement will never be executed. Now I looked a bit closer, and noticed that the "first" call to stat is actually not to *stat*, but to *lstat* in vanilla vdr-1.7.23, so if you remove the call to the second one, could it be that you're not really cutting redundancy, maybe it actually makes a difference? Lucian
On 13.02.2012 12:27, Lucian Muresan wrote: > On 13.02.2012 12:00, Klaus Schmidinger wrote: >> On 13.02.2012 11:44, Lucian Muresan wrote: >>> On 13.02.2012 10:43, Klaus Schmidinger wrote: >>>>> 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: >>> >>> [...] >>> >>>>> 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... >>>> >>>> ---------------------------------------------------------------------------------------------- >>>> >>>> >>>> --- 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)) { >>>> ---------------------------------------------------------------------------------------------- >>>> >>>> >>>> >>>> ...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. >>> >>> Haven't really looked at the code, until now, and I also do not >>> exactly know what the call to stat does and also didn't try to >>> understand the whole picture now, but your patch does not simply >>> remove just the call to stat, but also a *continue* statement from the >>> *while* loop, this could have strong >>> implications, so just please consider analyzing the issue with respect >>> to that. >> >> The original code was >> >> ---------------------------------------------------------------------------------------------- >> >> if (stat(buffer, &st) == 0) { >> int Link = 0; >> if (S_ISLNK(st.st_mode)) { >> if (LinkLevel > MAX_LINK_LEVEL) { >> isyslog("max link level exceeded - not scanning %s", *buffer); >> continue; >> } >> Link = 1; >> buffer = ReadLink(buffer); >> if (!*buffer) >> continue; >> if (stat(buffer, &st) != 0) >> continue; >> } >> ... >> } >> ---------------------------------------------------------------------------------------------- >> >> >> After Sundararaj's patch it looked like this (just leaving out the lines >> that his '#if 0' disabled): >> >> ---------------------------------------------------------------------------------------------- >> >> if (stat(buffer, &st) == 0) { >> int Link = 0; >> if (S_ISLNK(st.st_mode)) { >> if (LinkLevel > MAX_LINK_LEVEL) { >> isyslog("max link level exceeded - not scanning %s", *buffer); >> continue; >> } >> if (stat(buffer, &st) != 0) >> continue; >> } >> ... >> } >> ---------------------------------------------------------------------------------------------- >> >> >> Reducing this to the stat() calls results in >> >> ---------------------------------------------------------------------------------------------- >> >> if (stat(buffer, &st) == 0) { >> ... >> if (stat(buffer, &st) != 0) >> continue; >> } >> ... >> } >> ---------------------------------------------------------------------------------------------- >> >> >> As you can see, 'buffer' is no longer modified between the two calls, so >> they >> will both return the same value. The code sequence is only entered if >> the first >> stat() call returns 0, so the second call will also return 0, and thus the >> 'continue' statement will never be executed. > > Now I looked a bit closer, and noticed that the "first" call to stat is actually not to *stat*, but to *lstat* in vanilla vdr-1.7.23, so if you remove the call to the second one, could it be that you're not really cutting redundancy, maybe it actually makes a difference? Now you got me ;-) I had switched back to 'stat()' instead of 'lstat()' and forgotten to reintroduce the 'lstat()'. Therefore I saw two identical calls to stat(). With the first call being lstat(), the second call to stat() is of course necessary for the following S_ISDIR() check. Sorry for the confusion, and thanks for clarifying this. So now this whole code sequence looks like this: ---------------------------------------------------------------------------------------------- if (lstat(buffer, &st) == 0) { int Link = 0; if (S_ISLNK(st.st_mode)) { if (LinkLevel > MAX_LINK_LEVEL) { isyslog("max link level exceeded - not scanning %s", *buffer); continue; } Link = 1; if (stat(buffer, &st) != 0) continue; } ---------------------------------------------------------------------------------------------- Klaus
On 13.02.2012 12:54, Klaus Schmidinger wrote: > On 13.02.2012 12:27, Lucian Muresan wrote: >> On 13.02.2012 12:00, Klaus Schmidinger wrote: [...] >> Now I looked a bit closer, and noticed that the "first" call to stat >> is actually not to *stat*, but to *lstat* in vanilla vdr-1.7.23, so if >> you remove the call to the second one, could it be that you're not >> really cutting redundancy, maybe it actually makes a difference? > > Now you got me ;-) > I had switched back to 'stat()' instead of 'lstat()' and forgotten to > reintroduce > the 'lstat()'. Therefore I saw two identical calls to stat(). > With the first call being lstat(), the second call to stat() is of > course necessary > for the following S_ISDIR() check. > > Sorry for the confusion, and thanks for clarifying this. > So now this whole code sequence looks like this: > > ---------------------------------------------------------------------------------------------- > > if (lstat(buffer, &st) == 0) { > int Link = 0; > if (S_ISLNK(st.st_mode)) { > if (LinkLevel > MAX_LINK_LEVEL) { > isyslog("max link level exceeded - not scanning %s", *buffer); > continue; > } > Link = 1; > if (stat(buffer, &st) != 0) > continue; > } No problem at all, I'm glad it's now sorted out for the next developer version. Lucian
--- 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)) {