Permission plugin documentation incomplete and/or plugin behaving wrong

[SnoopAir]

Problem

I just had tried to import stuff from a network share which does not support/allow to set permissions. On import of some folders I get an error saying "Could not set permissions on .." - That's obviously correct. But the expectation is, that it sets the permission on the destination.

Led to this problem:

On import of some folders I get an error saying "Could not set permissions on .."
Here's a link to the music files that trigger the bug (if relevant):

Setup

• OS: Debian GNU/Linux 12 (bookworm)
• Python version: Python 3.11.2
• beets version: beets version 2.7.1

My configuration (output of beet config) is: (only partial)

# --------------- Plugins ---------------

plugins:
- bucket
- convert
- fetchart
- hook
- importadded
- inline
- lastgenre
- musicbrainz
- missing
- permissions
- replaygain
- scrub
- zero
- jdb


import:
    write: no
    copy: no
    move: no


permissions:
    file: 664
    dir: 775

Is this expected behavior? Aka is the documentation just missing this information? Or is it a bug?

[jackwilsdon]

With write, copy and move set to no, isn't your destination also the source?

[SnoopAir]

Yes and no. It's the attempt to mimic the not existing --dry-run flag.
Even IF it would mean what you imply, saying no to all for me implies: no changes what so ever, so neither destination nor source, no?

[jackwilsdon]

I don't quite understand what it is you're trying to do sorry. The permissions plugin sets permissions on file import - importing even with write, copy and move disabled is still an "import".

If it's only when doing certain imports you want it disabled, you can use the --disable-plugins option:

$ beet import --disable-plugins=permissions ...

[SnoopAir]

@jackwilsdon I'm trying to achive a "dry-run", to inspect what's going on (wrong) without modifying data. Due to the lack of such option for "beet import" I'm trying to mimic it without changing the config file or disabling plugins - because one of the goals is to see what a plugin does.

[jackwilsdon]

This seems like the expected behaviour of the permissions plugin to me.

We're always happy to improve our documentation - what is it specifically you'd like to see clarified?