Re: vdr 1.7.23: patch for handling symlinks in recordings directory as earlier

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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...

----------------------------------------------------------------------------------------------
--- 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.

Klaus

_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


[Index of Archives]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Big List of Linux Books]     [Fedora Users]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux