Cannot Move to NAS with "Move" about deluge-filebottool HOT 10 CLOSED

I have this problem too! But when it DOES work, it Filebot always leaves off the the first letter of the moved file. And of course I can't change it or the file will stop seeding and cause an error message in Deluge. :(

from deluge-filebottool.

That's strange, you should be able to do that, do any other file modes work (copy, symlink etc)? At fist glance it looks like a permission issue. FileBot will be launched with the same permissions that the deluge daemon has, so make sure that deluge has permission to write to the /media/Media directory.

from deluge-filebottool.

The deluge user has appropriate permissions, as I'm able to manually rename and move files within deluge. The FileBotTool can also rename files in place or anywhere on the same drive. It cannot move files to a different drive, even if they don't need to be renamed (I just manually moved a file back and tried to move it again using the tool). A buddy (who works for red hat) and I spent several hours the other day attempting to debug this as a permissions issue, to no avail.

The method being called is moveRename() in https://github.com/filebot/filebot/blob/master/source/net/filebot/util/FileUtilities.java.

which calls Files.Move() from
https://docs.oracle.com/javase/7/docs/api/java/nio/file/Files.html#move(java.nio.file.Path,%20java.nio.file.Path,%20java.nio.file.CopyOption...)

which seems to indicate that this method will throw an IOException when the destination is on a different FileStore.

If my understanding is correct, the best place to fix this would be upstream in the FileBot project itself, but I believe it would be possible to work around this by doing a copy and then delete.

from deluge-filebottool.

I forgot to mention also, that Copy mode does work, but defeats the purpose of the tool for me, which is to have organized files with no duplicates. and Links just seem messy. If nothing else, the easiest workaround is renaming the files in place with the tool, and manually using the "Move Storage" option in Deluge.

from deluge-filebottool.

Well that's a pain. I'll flag @rednoah to make sure he sees this. In the meantime, I'll see if I can find a reliable way to figure out if the destination is on a different filestore from within python and have deluge handle the output path moving.

from deluge-filebottool.

Thanks for looking into it. Like I said, I've figured out the closest thing to a workaround for now, and it only affects files that weren't caught by Flexget in the first place, so its not a huge deal.

from deluge-filebottool.

SMB/AFP/NFS filesystem abstraction is handled by the operating system, so FileBot doesn't even know if it's dealing with local or remote files. FileBot itself and the Java NIO.2 APIs just use the "local" filesystem, so all the SMB/AFP/NFS stuff is handled by the OS outside of the FileBot/Java process.

Googling all sorts of CIFS might get you lucky. If I were to thorougly debug the problem I'd look into how Files.move() is implemented on Posix platforms. Internally, Files.move() and mv should be calling the same Posix functions. Debugging the Java platform is it's own beast though. ;)

You might also want to look into any kind of app sandboxing like AppArmour and things like that. Maybe the process is prohibited from deleting the original file which makes the move fail?

from deluge-filebottool.

@Latinkidmj no logs => no support

from deluge-filebottool.

I'm going to close this since I can't really re-create it and it seems to be an OS issue.

from deluge-filebottool.

I was getting this in my filebot-node docker instance, and I figured out why, and wanted to document it for others who stumble across this thread. For me, the error was that input and output were on different filesystems (not really, but with the way docker was mounting bind volumes, it appeared that way to the app.

From a docker point of view, I was mounting source and destination as separate volumes:

 - /mnt/nas/media/video/todo:/volume1/input
 - /mnt/nas/media/video:/volume1/output

even though todo is just a peer level directory to Movies.

Before:
Input folder: /volume1/intput
Output folder: /volume1/output

resulted in:
[COPY] Failure: java.nio.file.FileSystemException: /volume1/output/Movies/someVideoName.avi: Operation not permitted

After:
Input folder: /volume1/output/todo
Output folder: /volume1/output

That change had it appear to Filebot & Java that it was working on the same volume / filesystem and the program ran without a problem and moved my files where I expected.

Hope this helps someone!

from deluge-filebottool.