Add file relocation and renaming api for v3 #1081
Conversation
- refactored VideoLocal_Place, moved some methods out, and organised the rest into regions. - we now use request objects when moving/renaming and there is only one method for each operation. - kept the retry logic we did on import, it will now retry regardless of where the operation was ran from (e.g. from the rename util in desktop, during import, from a RESTful client, etc.). - Reworded some of the error messages - Desktop now shows the full path if the option to move is selected, otherwise it will show just the file name.
and generate them dynamically for the v1 api
- don't allow a preview when directly relocating a file - when a move/rename destinaiton is found, skip the actual operation if we're only previewing the destination. - always display the full path in the v1 api - add missing parameter usage in the v3 api for direct relocation - add back logging of source and destination
add per-file toggles for auto-relocation and for auto-deletion still WIP. missing database migrations and model mappings.
| @@ -15,5 +15,7 @@ public VideoLocal_PlaceMap() | |||
| Map(x => x.FilePath).Not.Nullable(); | |||
| Map(x => x.ImportFolderID).Not.Nullable(); | |||
| Map(x => x.ImportFolderType).Not.Nullable(); | |||
| Map(x => x.AllowAutoRelocation).Not.Nullable(); | |||
There was a problem hiding this comment.
Why? Per file overrides on this seem completely unnecessary
There was a problem hiding this comment.
To prevent it from being automagically moved, e.g. you place a copy at one location for it to stay there, and not be moved away by shoko. If we had a better renaming system that allowed the user to specify all the paths you would want for a file then I don't it will be needed, no. But until then then I have a personal need for this per-file-location setting to exist.
There was a problem hiding this comment.
An good example is for Toriko EP1 / One Piece EP420(?), where I would want to place a hard copy in both directories, and have Shoko not touch them.
There was a problem hiding this comment.
Well it won't get moved if it's in a destination. For predictability and reproducibility, you want your script to give it exactly one place it should go.
There was a problem hiding this comment.
Also, I think i forgot to expose a way to toggle the per-file location settings (allow auto relocate and allow auto delete) in the api…
There was a problem hiding this comment.
That's a fair example, I guess. It's a very niche feature.
There was a problem hiding this comment.
This sounds a bit like over-engineering an issue that isn't really there.
|
Will this PR make it possible to have one source import folder and another destination import folder where the files don't get moved but linked or copied instead? If yes awesome. Does it work well enough to test it? |
|
No. Copying isn't really a good idea anyway. If you want copies, then use a copy on complete script in your downloader. |
|
In case you didn't know @da3dsoul, i added and have tested adding hard linking support in this PR. They won't be made automatically by any renaming script, but it's possible to create them through the REST v3 API in this PR as of right now. |
|
Also when hard linking (or just creating another location in general) then the two locations will automatically be excempt from auto deletion. |
|
There are a few things to change up, so I've converted this PR to a draft for now, since I'm focusing on the other PR for adding TMDB support. |
While it might make that possible it won't make it possible with a traditional renamer, you would have to use the file events directly and also either use the REST api or reference the shoko dlls directly and not using the abstraction. |
I've tested the new file endpoints to a degree (on linux using sqlite), moving files around, renaming them, creating hard and soft copies, and squashed a few bugs while I was at it.
So this PR adds renaming to the v3 api, and cleans up the move/rename internals, adapts the v1 api to the new internals, among other things.