filesystem_spec
filesystem_spec copied to clipboard
Error on mv using DirFileSystem with fs=SMBFileSystem
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:
- mv throws an error when used in this way. Simple enough.
- 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.
Agreed, dirFS's mv should call its child filesystem rather than depending on the base class implementation.
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)
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.
Hello guys, I faced the same issue so I pushed a PR for it here: https://github.com/fsspec/filesystem_spec/pull/1582
Not sure what you meant @ArtnerC about the async part, not relevant here imho; let me know if I missed something
Thanks for handling this!