[mythtv-users] no write(2) method for mythfs.py?

[Raymond Wagner]

On 11/23/2011 10:27, Brian J. Murrell wrote:
> I'm trying to use mythfs.py to fix a broken recording but I notice that
> when I try to write to a path I get -EACCES which I guess is because:
>
>      def open(self, path, flags):
>          LOG(LOG.FILE, 'requesting file open', path)
>          accmode = os.O_RDONLY | os.O_WRONLY | os.O_RDWR
>          if (flags&  accmode) != os.O_RDONLY:
>              return -errno.EACCES
>
> and I guess a missing write() method.
>
> Is there any reason beyond the simple case of "who would want to write
> to a recording file?" that write(2) was not implemented?

No, that's pretty much it.  There is a whole lot that would have to go 
on behind the scenes to make such a thing work.  The recording would 
have to be marked as in-use for writing.  The filesize would need to be 
updated.  The seek table would have to be invalidated and flushed, 
potentially along with any bookmarks and markup.  The backend protocol 
does not currently implement moving files, so would would have to be 
implemented to write the new copy to a temporary file, delete it, and 
shift the new one in place.  Alternatively, the original would have to 
be buffered locally while the old one was deleted and written on top of.

Now some of this could be automated, hidden from the user.  Potentially 
others could be tucked away into special text files the user could 
access to modify metadata and seek/skip/cut tables.  To be honest, when 
you need more access to the internals than a filename can provide, it 
seems like it would be easier on both sides to just implement the 
database and protocol access natively in whatever tool you're using to 
fix those files.

> On a side note, I am also noticing that the first (read) access to a
> file fails but a second access succeeds.

That's not one I've seen before.  Although to be honest, I haven't used 
mythfs in well over a year.  There only issue I recall off hand was one 
where the bindings were not properly maintaining a persistent connection 
for long durations, and mythfs had to be restarted to resolve the 
issue.  There is code in the bindings to continually restart the 
connection in the event it gets disconnected, but it was throwing an 
unhandled exception somewhere and that thread was dying.  I haven't been 
using it due to memory issues I was having, specifically the python fuse 
bindings caching far too much data internally, causing the rest of the 
system start swapping heavily.

> On a secondary side note, I also notice that mythfs.py doesn't seem to
> wake the backend the way a configured FE would using the "WOLsqlCommand"
> in ~/.mythtv/mysql.txt.

This is just something I never bothered implementing in the bindings, 
for no real reason other than I didn't personally have a use for it.  It 
shouldn't be all that hard to add, just a couple lines to call the 
specified program with timeout parameters, and a mutex.