[mythtv] [mythtv-commits] Ticket #6726: Patch mythrename.pl to add '--hardlink' option

[Michael T. Dean]

On 07/14/2009 11:05 PM, MythTV wrote:
> #6726: Patch mythrename.pl to add '--hardlink' option
>
>  This is a patch to mythrename.pl to add a '--hardlink' option.  When
>  scanning an NFS share over the network with a device such as a Popcorn
>  Hour, symbolic linked files will list in the directory contents, but can't
>  be played (retrieved) due to the way NFS handles (or doesn't handle)
>  symbolic links.  The patch adds a new option '--hardlink' to the
>  mythrename.pl script that works exactly the same as the '--link' option,
>  only it creates/deletes hard links instead of symbolic links.

This behavior seems like it would be very dangerous.

The first issue with it is that hard links can only be created on the 
same device as the source file.  So, if you use multiple filesystems via 
Storage Groups (even if they're all physically on the same host), hard 
linking to all recordings would be impossible.

The second--and /much/ larger issue--is that hard links provide /no/ 
information about the relationship between source and destination 
files.  Therefore, when you delete a recording in Myth, Myth would be 
unaware that the hard linked filename exists and would be unable to 
delete the additional filename--even if you enable "Follow symbolic 
links when deleting files" (as it's /not/ a symbolic link and can /not/ 
be followed).  Therefore, someone would have to manually go through and 
delete the hard linked filename for the filesystem space to actually be 
freed.

Currently, mythrename.pl /only/ deletes "files" in the pretty link dir 
if they're symlinks--a safety feature done to minimize the chance of its 
deleting content it didn't create.  If changed to delete all files, it 
could delete something it shouldn't.

And, if nothing else, on some filesystems (like ext3) where deletes can 
take a long time, if myth had deleted the original filename (which would 
happen in almost no time if you do not enable, "Delete files slowly," 
since the file still exists/inodes are still in use), mythrename.pl's 
deleting the hard-linked filename would take a long time (potentially 
problematic if mythrename.pl is run frequently in a cron job).  However, 
if you enable, "Delete files slowly" (as most ext3 users would), Myth 
would go through and truncate the file until it was less than about 4MB 
before it deletes the original filename.  Therefore, the hard-linked 
filename would reference the remaining (less than) 4MB file, which would 
leave little bits of garbage in the filesystem.  Even if you checked 
filesize before deleting, deleting a non-link file may allow the script 
to delete files it shouldn't.

And, there's a simple workaround to "the way NFS handles (or doesn't 
handle) symbolic links"--simply have the filesystem layout mirrored on 
all systems.  And, since that's the recommended approach for using NFS 
filesystems with Myth, you probably should do that, anyway.  Because 
mythrename.pl creates links with absolute paths, this means that the 
entire path must be mirrored on all systems.  Here's a nice description 
of how to use symlinks with NFS (thanks, Allan Stirling, for digging it 
up): 
http://ou800doc.caldera.com/en/SDK_sysprog/_Using_Symbolic_Links_with_NFS.html 


For those users using CIFS/Samba, if you want the server to "follow" 
symlinks for the client, simply disable Unix extensions.  So, add the line:

unix extensions = No
follow symlinks = Yes
wide links = Yes

to the "[global]" section of your smb.conf.  (Thanks to Raymond Wagner 
for tracking down the current settings.)

If you don't want to mirror the absolute path structure on all hosts, 
then mythrename.pl's insistence on creating absolute symlinks may be the 
issue.  If so, it may make more sense to instead patch mythrename.pl to 
allow creation of directory-relative symlinks.  For example, an argument:

--relative-links <base dir>

Create symbolic links relative to the specified <base dir> instead of 
using the recording file's absolute path.  <base dir> may contain 
path-relative specifiers, such as "." and "..".  Note that using 
--relative-links will create symlinks that only work from certain 
directories, so may not be usable with certain applications, including 
media players, or my only work if starting those applications from an 
appropriate directory.

would allow you to create symlinks that would work even if the absolute 
paths differ across hosts.

Mike