Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Copying metadata between FS objects #409

Open
SF-300 opened this issue Jun 28, 2020 · 1 comment · May be fixed by #426
Open

Copying metadata between FS objects #409

SF-300 opened this issue Jun 28, 2020 · 1 comment · May be fixed by #426
Assignees
Milestone

Comments

@SF-300
Copy link

SF-300 commented Jun 28, 2020

Hi!

I'm looking for a way to copy/mirror data from ReadTarFS to OSFS. Everything works fine unless the archive contains symlinks. All copy/mirror methods are implemented via copy_file_internal function which in turn calls openbin method of appropriate FS-inherited object. And in ReadTarFS implementation of openbin there is

        if not member.isfile():
            raise errors.FileExpected(path)

I get why this check is there - the library strives to be a lowest common denominator for different filesystems and symlinks are not universally-supported. I believe that my current issue can be solved by patching if not member.isfile() to if not (member.isfile() or member.issym()) and using fs.copy.copy_fs with on_copy callback to alter metadata with setinfo call (as symlinks are simply text files with magic attribute set on them).

But it feels that a more general problem lurks there. Currently there is no sane way to customize copying (of both data and metadata) for cases when both filesystems actually support the same set of features and thus it's safe to copy some exotic types of files (like symlinks/sockets/devices/... in tar and ext4).

I like the idea behind this library but lack of such feature makes it unusable for my case. Off the top of my head I can think of one solution. What do you think about it?

PS: Thanks for your time and for an interesting piece of software! =)

@althonos
Copy link
Member

I think the issue here is actually coming from the ReadTarFS implementation.

If you look at the implementation of OSFS (which also powers AppFS and TempFS), openbin will follow the symlink and simply open the linked file. Now, Pyfilesystem2 does not really have a clear behaviour related to symbolic links, but I'd expect them to just work if the link happens to point to a file.

@althonos althonos self-assigned this Sep 19, 2020
@althonos althonos linked a pull request Sep 19, 2020 that will close this issue
10 tasks
@althonos althonos added this to the v2.5.0 milestone Sep 30, 2020
@althonos althonos added the bug label Sep 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants