Re: [Duplicity-talk] gpg key password asked for backup after verify

[Kenneth Loafman]

I don't know what the underlying code looks like for non-POSIX systems, and I don't have a Windows/Cygwin system to test against, so my answer would be that I would prefer it be done in _librsyncmodule.c since that seems to be the only place that needs it.  Failing that, librsync.py is my second preference since it's only one level up.

We would still leave the error check  on line #305 since we could have made a different error.  We would need to set the error message accordingly.

...Ken

On Mon, May 29, 2017 at 8:47 AM, edgar.soldin--- via Duplicity-talk <address@hidden> wrote:

Ken,

On 29.05.2017 14:27, edgar.soldin--- via Duplicity-talk wrote:
> On 29.05.2017 13:26, Kenneth Loafman wrote:
>> 1) This was from the README for 0.7.05:
>>
>>         * Fix bug #1494228 CygWin: TypeError: basis_file must be a (true) file
>>
>>           - The problem that caused the change to tempfile.TemporaryFile was due
>>
>>             to the fact that os.tmpfile always creates its file in the system
>>
>>             temp directory, not in the directory specified.  The fix applied was
>>
>>             to use os.tmpfile in cygwin/windows and tempfile.TemporaryFile in all
>>
>>             the rest.  This means that cygwin is now broken with respect to temp
>>
>>             file placement of this one file (deleted automatically on close).
>
> wrt. os.tmpfile() .. afaics. does
>
>    https://hg.python.org/cpython/file/2.7/Lib/tempfile.py#l484
>
> use the os module ( os.open, os.fdopen ) all around to create temp files. aren't these supposed to return a (true) file? the docs say nothing in this regard. https://docs.python.org/2/library/os.html#file-object-creation
>
> ..ede
>

ok answering myself here, after reading the original bug report thoroughly, which says
"
The problem is that, as explained in the Python documentation (http://docs.python.org/library/tempfile.html), tempfile.TemporaryFile returns a *file-like* object, not a file object. Under Linux, it effectively returns a file object but under windows it does not. Hence, the type of the object returned is *not* a types.FileType, causing the exception to be raised.
"
  https://bugs.launchpad.net/duplicity/+bug/670891

further reading shows that the error stems from 'duplicity/librsync.py'
"
  File "/usr/lib/python2.6/site-packages/duplicity/librsync.py", line 167, in __init__
    raise TypeError("basis_file must be a (true) file")
"


so obviously something is done differently in the 'duplicity/_librsyncmodule.c', that needs a delta patch file to be a plain File object. let's see 'duplicity/librsync.py' says
"
class PatchedFile(LikeFile):
    """File-like object which applies a librsync delta incrementally"""
    def __init__(self, basis_file, delta_file):
        """PatchedFile initializer - call with basis delta

        Here basis_file must be a true Python file, because we may
        need to seek() around in it a lot, and this is done in C.
        delta_file only needs read() and close() methods.

        """
        LikeFile.__init__(self, delta_file)
        if not isinstance(basis_file, types.FileType):
            raise TypeError("basis_file must be a (true) file")
        try:
            self.maker = _librsync.new_patchmaker(basis_file)
        except _librsync.librsyncError as e:
            raise librsyncError(str(e))
"
http://bazaar.launchpad.net/~duplicity-team/duplicity/0.8-series/view/head:/duplicity/librsync.py#L163


and in 'duplicity/_librsyncmodule.c' it tries to utilize 'PyObject_AsFileDescriptor(python_file)'
"
/* Call with the basis file */
static PyObject*
_librsync_new_patchmaker(PyObject* self, PyObject* args)
{
  _librsync_PatchMakerObject* pm;
  PyObject *python_file;
  int fd;

  if (!PyArg_ParseTuple(args, "O:new_patchmaker", &python_file))
    return NULL;
  fd = PyObject_AsFileDescriptor(python_file);
"
http://bazaar.launchpad.net/~duplicity-team/duplicity/0.8-series/view/head:/duplicity/_librsyncmodule.c#L294


so, if i understand correctly, we just have to implement the method 'fileno()' as described here
  https://docs.python.org/2/c-api/object.html#c.PyObject_AsFileDescriptor
in another wrapper around the tempfile.TemporaryFile() return value
  https://docs.python.org/2/library/tempfile.html#tempfile.TemporaryFile
, utilizing (if necessary) the file-like object's file attribute as mentioned in the python doc and return
"
The returned object is a true file object on POSIX platforms. On other platforms, it is a file-like object whose file attribute is the underlying true file object.
"

implementing that should render the failing TypeError("basis_file must be a (true) file") in 'duplicity/librsync.py' meaningless, so it could be removed or?

alternatively, we could simply extend 'duplicity/librsync.py', to test for a file attribute, in case the "file" object given is just a wrapper. on success we then simply deliver that (pseudo code)
"
self.maker = _librsync.new_patchmaker(basis_file.file)
"

what do you think Ken? would that work? which approach would you prefer? ..ede

_______________________________________________
Duplicity-talk mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/duplicity-talk