Error on mv using DirFileSystem with fs=SMBFileSystem

[ArtnerC]

I am attempting to use the DirFileSystem to wrap SMBFileSystem so I can operate in my SMB folder as though it's my base directory. I can use most methods I need just fine. For example mkdirs and cp work as expected.

However, when I use mv I get TypeError: get_smb_tree() got an unexpected keyword argument 'recursive'

From the stack trace, I can see that this is actually using the mv method from the AbstractFileSystem class instead of the SMBFilesystem. SMBFileSystem implements mv correctly but the fallback in AbstractFileSystem performs a copy (with recursive passed in) and delete. This happens (I think) because DirFS inherits from AsyncFileSystem which doesn't require move to be implemented.

This is problematic for two reasons:

1. mv throws an error when used in this way. Simple enough.
2. I would like to be able to use the SMB move functionality specifically, because I don't want my created and modified timestamps to change. Copy updates both timestamps.

Also, I'm happy to do work towards implementing a fix, but I don't know where to start to keep with the intended vision of this library.

[martindurant]

Agreed, dirFS's mv should call its child filesystem rather than depending on the base class implementation.

[martindurant]

Also, I'm happy to do work towards implementing a fix, but I don't know where to start to keep with the intended vision of this library.

Are you still interested? It would involve implementing a method mv() for dirFS which calls the underlying filesystem, something like

    def mv(self, origin, dest, **kw):
        self.fs.mv(self._join(origin), self._join(dest), **kw)

[ArtnerC]

Definitely interested and I implemented a similar function as a temp workaround in my project. The one thing that will slow me down is that the Dirfs is implemented asycnc and I'm not super experienced with that. I'll take a crack at it in the next few days.

[nilshamerlinck]

Hello guys, I faced the same issue so I pushed a PR for it here: #1582

Not sure what you meant @ArtnerC about the async part, not relevant here imho; let me know if I missed something

[ArtnerC]

Thanks for handling this!