Copy file support

[breadcat]

Hello there, great project really enjoying things so far.

I've noticed that when processing files the default is to move (which is fine), but I'd like an option to be able to copy files instead so I'm able to leave them seeding in my torrent client. I just plan on just skipping files that have already been processed.

Is this a possibility?

[jpillora]

Yep, would be fairly easy

Just make this call to move https://github.com/jpillora/media-sort/blob/master/sort/fs_sort.go#L303 take another parameter fs.Copy and add a new Copy flag to the fs struct

Would you be able to send a PR?

[breadcat]

Thanks for the reply. I'm sorry, even simple things in go are beyond my current understanding of the languages. I'll try to improve my understanding and submit a PR.

[rotsix]

Hey there. Another improvement would be to provide either move, copy, or link the new files.

Edit: by linking, I mean symbolic links to support cross-device rename.

[jpillora]

Yep, --action <move|copy|link> defaulting to move might be nice

symbolic links to support cross-device rename.

How does a symlink implement a cross device rename? Currently I'm shelling out to mv to do cross-device moves, which I assume is basically a cp+rm

[rotsix]

Yep, --action <move|copy|link> defaulting to move might be nice

I had the exact same idea!

Symlinks don't support renames, as they don't refer to an inode, but to a filename directly. I don't think that a major issue, simply removing the simlinks and running the program again would recreate them.

Edit: here is a commit to allow the use of symlinks. I test it, and can also work on the --action flag when I get some time.

[jpillora]

Ah right, I guess that’ll work. I’ll see what I can do

On Sat, 6 Jun 2020 at 9:59 pm Victor Franzi notifications@github.com wrote:

Yep, --action <move|copy|link> defaulting to move might be nice

I had the exact same idea!

Symlinks don't support renames, as they don't refer to an inode, but to a filename directly. I don't think that a major issue, simply removing the simlinks and running the program again would recreate them.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/jpillora/media-sort/issues/17#issuecomment-640048460, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAE2X4ZWKJLZ4JOSUHAWGR3RVIVTBANCNFSM4KCB4GDQ .

[rotsix]

I can submit a PR if you want, that I'll improve to include the --action flag later?

[jpillora]

Sure, probably the —action flag is the way to go up front so we don’t have to do redo it

I’m thinking of the function:

fsAction(action action, filepath string) error

Which can be placed in OS specific go files. We can throw an “unimplemented” error, when doing a copy or link, in the windows version for now.

Where action is:

type action string

const ( ... 3 action enums )

That sound okay for your PR?

On Sat, 6 Jun 2020 at 10:07 pm Victor Franzi notifications@github.com wrote:

I can submit a PR if you want, that I'll improve to include the --action flag later?

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/jpillora/media-sort/issues/17#issuecomment-640049774, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAE2X4Z4KQ5D4OA2F6FKSEDRVIWR7ANCNFSM4KCB4GDQ .

[rotsix]

Why not. I was more thinking of a wrapper like this:

func (fs *fsSort) action(src, dst string) (err error) {
    // switch on the fs.Action field (inherited from Config)
    // the link type is already provided by my previous commit
}

And within this function, it would just call move, link or copy, which would be like this:

func move(src, dst string) error){ ... }

These functions would be architecture-specifics, so in the fs_sort_<arch>.go files.

You agree?

[jpillora]

PR looks pretty good! Just a few minor comments :)

[jpillora]

closed with #23