Filer_Action copy filetype bug
Rik Griffin (98) 264 posts |
Over here: https://www.riscosopen.org/forum/forums/9/topics/997?page=17, Ben describes a bug in Filer_Action to do with setting the incorrect filetype when copying (?) Ben – could you provide a few more details please and possibly a simple test case? I’m reasonably familiar with the internals of Filer_Action so I’ll have a go at fixing this when I get some free time. Cheers |
Jeffrey Lee (213) 6048 posts |
I believe Ben’s already fixed it (and an identical bug in *copy). But in summary, copying a directory over an image file was causing the filetype of the directory to be applied to the image file, therefore rendering the image file useless (since directories have a filetype of data) |
Rik Griffin (98) 264 posts |
Oh right then :) |
Willi Theiss (541) 17 posts |
With Filer_Action v0.57 there is a (new) bug when copying zip (filetype &a91) or archive (filetype &ddc) files when SparkFS is loaded: the copied file gets a filetype data (&ffd). When SparkFS and its FS modules are not loaded then there is no problem. |
Chris Johnson (125) 825 posts |
Yes, I noticed that last night when transferring some zip files from Iyonix to ARMini, and then copying them again on the ARMini to a new location. I didn’t have time to investigate what sequence of actions was required to provoke this behaviour. |
Jeffrey Lee (213) 6048 posts |
It looks like this could be down to a mistake in Ben’s fix. Instead of checking for “objecttype & object_directory”, it should be checking for “objecttype == object_directory”. On the other hand the fix for *copy look fine (although I won’t be able to test until I get home) |
Jeffrey Lee (213) 6048 posts |
This is now fixed in v0.58. |
Ben Avison (25) 445 posts |
Oops! Sorry folks. I’m a bit surprised this wasn’t spotted earlier. Thanks for fixing it, Jeffrey. |