[mythtv] [mythtv-commits] Ticket #1216: mythrename.pl renames symlinks while target filename stays the same - breaks 'recorded' table
Michael T. Dean
mtdean at thirdcontact.com
Mon Feb 6 01:00:46 UTC 2006
On 02/05/06 18:16, Tom Lichti wrote:
>>#1216: mythrename.pl renames symlinks while target filename stays the same -
>>breaks 'recorded' table
>> I think mythrename.pl should either verify that a file name actually
>> belongs to the host where the script is run ('hostname' field) or not mess
>> with symlinks. It may be necessary/good to check it against the
>> 'LocalHostName' in mysql.txt (if it's there), but I'm not sure if
>> mythbackend actually honors this setting.
>That's how it's supposed to work. Are you using the latest version from SVN?
Actually, we're only checking for the existence of a file--not checking
whether it's a symlink or a file.
We haven't been checking if a recording is "owned" by a specific host so
that users who share their recordings directory using NFS don't have to
run mythrename.pl on all their backends (instead of just one--not a big
deal for a cron job making symlinks, but a pain for people actually
Ignoring symlinks also has its negatives in that those using
mytharchive.pl (or manually using links) to store recordings in other
filesystems would be unable to rename the links.
So, hansi.urpils, does symlinking the recordings from the mounted master
backend's recordings directory to your slave backend's recordings
directory require manual intervention or did you hack up a script for
it? I'm guessing you're one of the only (possibly the only) person who
is using this setup--I'm pretty sure most either share a single
recordings directory via NFS or keep their slave and master recordings
directories separate. If there aren't many people doing this, perhaps
waiting for storage groups would be a better approach (
More information about the mythtv-dev