Hello klaus
One of the changes you introduced in 1.7.16 does prevent the deletion of ".del" directories and the files inside of video.01, video.02 and so on.
Only the del directories in video.00 with the symbolic links are cleaned up by the removing recordings thread.
I guess it is caused by this change from 1.7.15:
- Fixed following symbolic links in RemoveFileOrDir().
This bug has been confirmed by other users in vdr-portal.
Any ideas what I can change in the code until 1.7.17 comes out?
Thanks and regards
Lou@vdr-portal
On Tue, Oct 12, 2010 at 8:50 AM, Lou tuxoholic@hotmail.de wrote:
One of the changes you introduced in 1.7.16 does prevent the deletion of ".del" directories and the files inside of video.01, video.02 and so on.
Only the del directories in video.00 with the symbolic links are cleaned up by the removing recordings thread.
I guess it is caused by this change from 1.7.15:
- Fixed following symbolic links in RemoveFileOrDir().
This bug has been confirmed by other users in vdr-portal.
Any ideas what I can change in the code until 1.7.17 comes out?
Assuming nothing like function params have changed, you could try just copying that function from 1.7.15.
On Tue, 12 Oct 2010 10:10:07 -0700 VDR User user.vdr@gmail.com wrote:
On Tue, Oct 12, 2010 at 8:50 AM, Lou tuxoholic@hotmail.de wrote:
One of the changes you introduced in 1.7.16 does prevent the deletion of ".del" directories and the files inside of video.01, video.02 and so on.
Only the del directories in video.00 with the symbolic links are cleaned up by the removing recordings thread.
I guess it is caused by this change from 1.7.15:
- Fixed following symbolic links in RemoveFileOrDir().
This bug has been confirmed by other users in vdr-portal.
Any ideas what I can change in the code until 1.7.17 comes out?
Assuming nothing like function params have changed, you could try just copying that function from 1.7.15.
that should work but doesn't fix anything for the next version ;) (well thats not that has been requested, but it needs to be fixed anyway :) ) - question: is there a reference to the original problem that should be fixed by that ? I can confirm this.As told by Lou it should be the change in tools.c -> RemoveFileOrDir()
On 12.10.2010 17:50, Lou wrote:
Hello klaus
One of the changes you introduced in 1.7.16 does prevent the deletion of ".del" directories and the files inside of video.01, video.02 and so on.
Only the del directories in video.00 with the symbolic links are cleaned up by the removing recordings thread.
I guess it is caused by this change from 1.7.15:
- Fixed following symbolic links in RemoveFileOrDir().
This bug has been confirmed by other users in vdr-portal.
Any ideas what I can change in the code until 1.7.17 comes out?
Thanks and regards
Lou@vdr-portal
The patch was originally suggested by "atinar" at
http://www.vdr-portal.de/board/thread.php?postid=920661#post920661
and I adopted it with a suggestion from "Urig". Looks like nobody tested the patch in
http://www.vdr-portal.de/board/thread.php?postid=936545#post936545
otherwise this malfunction might have been detected earlier ;-)
Unless "atinar" or somebody else comes up with a fixed version of this patch, I'll simply revert to the previous version.
Klaus
On Tue, 12 Oct 2010 23:56:16 +0200 Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:
On 12.10.2010 17:50, Lou wrote:
The patch was originally suggested by "atinar" at
http://www.vdr-portal.de/board/thread.php?postid=920661#post920661
and I adopted it with a suggestion from "Urig". Looks like nobody tested the patch in
http://www.vdr-portal.de/board/thread.php?postid=936545#post936545
otherwise this malfunction might have been detected earlier ;-)
Unless "atinar" or somebody else comes up with a fixed version of this patch, I'll simply revert to the previous version.
Actually the only way the size of readlink() can exceed the size of the filename, is if the encoding of the filename on the linked-to directory is different, then the one of the original file. Assuming UTF-8 has max 4 byte per character, int size = strlen(buffer) * 4; should be fair enough. The length of the subtitle should not matter, as the original filename should have the same length as readlink if the encoding would be the same.
If you don't want to make assumptions, i think this is the culprit: + else if (n < size) {
as n is equal size (as we read the size before )
So this : + else if (n < size) { + l[n] = 0; + dsyslog("removing %s", l); + if (remove(l) < 0) + LOG_ERROR_STR(l); + } + else + esyslog("ERROR: symlink name length (%d) exceeded anticipated buffer size (%d)", n, size); + free(l);
should maybe be something like this: + else { + l[n] = 0; + dsyslog("removing %s", l); + if (remove(l) < 0) + LOG_ERROR_STR(l); + } + free(l);
On Tue, 12 Oct 2010 23:56:16 +0200 Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:
Unless "atinar" or somebody else comes up with a fixed version of this patch, I'll simply revert to the previous version.
find attached the patch. - use lstat - don't check if (n < size) as it should be same
I have tested this and its working.
Steffen