-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Use shutil.move() to move files. #5123
base: master
Are you sure you want to change the base?
Conversation
Hmm, one of the commits that popped up in the
I didn't check thoroughly, so there may be more differences to |
Good catch. We do want to copy file permissions though, that's causing several problems. I'll see if I can setup a samba share to test on as well. If that still causes problems maybe trying shutil.move() and then the more complicated algorithm may be the way to go unless anyone has any other ideas. |
I think the more complicated version is there for a reason. I don't want to remove a large amount of code without a good justification and a fair amount of testing. Perhaps a separate rule for files originating in Also, I am the one that made |
Thanks for the feedback! I'm getting this problem with more than just fetchart, music files imported normally (I think it's mostly when importing across filesystems or from a .zip file) also are created with the wrong permissions. So just changing the logic in fetchart wouldn't fix this other problem I'm having. Maybe the best solution here then would be to make sure that this function preserves permissions when moving. I may need help with testing any changes in more esoteric situations. And then possibly changing fetchart to create the temp file with more normal permissions if still needed. Does that sound like a good solution? Are there any other concerns you have here with any changes? |
Preserving or changing permissions seems like a good fix, since it seems according to that commit message that it's only a specific part of the metadata that SAMBA rejects. The fetchart temp file was implemented because, when loading from a file already on disk, if there were modifications specified by the settings (such as resizing) then those would first be performed on the original file before it was moved, changing it. So I made it copy everything to a file in memory (which is what If possible, reading the umask might be a good option. If the user has that set then it should be honoured wherever possible. There's a bit of wiggle room with technically copying files but even specifying that if there's no umask value, we use 755 (the default umask on Linux) then I think that's a fine compromise. That won't cause any problems for users beyond possibly being too wide, and if it is, then the user would have the system knowledge to fix that. If you're running beets on a system where those file permissions matter and you haven't set umask to something else, then you can't really be helped. I think the general priority should be:
What do you think about that? (Also, if you rebase off master, the formatting CI will work :) ) |
1790451
to
908134d
Compare
OK, this should be the bare minimum to try to copy file permissions. I think that this shouldn't raise any errors based on the docs, but if someone could test what happens when you use it on windows or with a samba share that would be useful. |
@aereaux given that copying the metadata is a somewhat optional action, we probably do not want any possibility of exceptions here. Consider wrapping the |
Do you know what possible error types that could raise? It would probably be good to just suppress those error types. |
Good point. We should probably respect users pressing CTRL-C meanwhile 😁 I think |
Just pushed this change. Is there anything else that would need to be added for this to get merged? |
Description
Fixes #4622.
I don't think this changes other behavior of the function, but it fixes the problem with the moved files being created with the wrong permissions for me.
To Do
docs/changelog.rst
to the bottom of one of the lists near the top of the document.)