`atomic_rename` failure on Windows Python2.7 about persist-queue HOT 7 OPEN

py27 was passed on CI: https://ci.appveyor.com/project/peter-wangxu/persist-queue/builds/19169922

what's the type of src and dst?

from persist-queue.

src = 'c:\\users\\liangr\\appdata\\local\\temp\\tmpol0feq'
dst = 'c:\users\liangr\appdata\local\temp\tmpsulfcsstorops\info'

('type(src)', <type 'str'>)
('type(dst)', <type 'unicode'>)
('isinstance(src, _str)', False)
('isinstance(dst, _str)', True)
('isinstance(src, _bytes)', True)
('isinstance(dst, _bytes)', False)

from persist-queue.

Most of storops python source files set from __future__ import unicode_literals. This would make any string literal to be unicode.

In TestPQueue of storops,

from __future__ import unicode_literals
# ... ...
self.path = tempfile.mkdtemp(suffix='storops')
self.q = tasks.PQueue(self.path)

And this would make _infopath in Persist-Queue and dst of atomic_rename to be unicode.

While in Persist-Queue, unicode_literals is not imported. And src of atomic_rename is returned by tempfile.mkstemp(), so it is str.

That is the reason what we got as the above comments.
src is str, dst is unicode.

So the conclusion is that any source codes with unicode_literals imported could meet this issue.

Can we convert the type of src or dst to make them as the same type first?

from persist-queue.

@Murray-LIANG loooooking forward to your change:)

from persist-queue.

Sorry for the late response. I will do the fix next days. My proposal is that converting the src and dst to str or unicode first regardless of their original types.

What I don't understand is that why it chooses different ctypes move functions based on the type of file paths?

from persist-queue.

AFAIK, this is the windows API limitation, MoveFileExW for unicode MoveFileExA for ascii only.
Agreed with you to convert, and we can use the former function for both str or unicode.

from persist-queue.

@Murray-LIANG any update?

from persist-queue.