Closed reidsunderland closed 12 months ago
yeah... so ... the issue is that DESTFNSCRIPTS entry points are being called in the routines that set up msg['new_dir'] and msg['new_file'] for after_accept entry points that run later... so it's kind of a inception issue where msg['new_file'] should be set before DESTFNSCRIPTS is called, but DESTFNSCRIPTS is called to help set msg['new_file']...
a couple of different approaches as possible...
but the thing is, msg['new_file'] is set with the return value from that call when it is active... hmm... ponder a bit.
I have a fix, but it is a bit terrifying...
I'm worried that there is a reason is was where it was in the sequence. This is reversing the order of calls to getDestInfos and set_dir_pattern (v2 name... sr3 is: sundew_dirPattern ) I worry that the dirPattern thing uses stuff set in destfnscript somehow... now it looks like destfnscript is just about filenames, and dirPattern is about setting the new_dir (the directory the file will end up in.) ... so ... looks ok.
Many internal plugins were written assuming that
msg['new_file']
would exist within a destfn plugin. But destfn plugins are invoked beforemsg['new_file']
gets set.This might be not a problem - the developer can use
msg['relPath'].split('/')[-1]
to get the filename.But other plugins have
msg['new_file']
available, so maybe it's more intuitive if destfn scripts also have new_file.@petersilva is looking at related parts of the code for #772.