[mythtv-users] no write(2) method for mythfs.py?
raymond at wagnerrp.com
Wed Nov 23 17:56:44 UTC 2011
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.
More information about the mythtv-users