Maybe @Squid need to blacklist other versions until then,if they not working for users not confusing... 

Can someone confirm that privios version 2024 working fine on unraid 6.9.x? Then I should make new version min for unraid 7.0

I am still on 6.12.15 (and will wait a 7.X update before moving to 7).

3 hours ago, NLS said:

I am still on 6.12.15 (and will wait a 7.X update before moving to 7).

So version you using is working fine? 

I'm on unraid 7 and tried both your newest version and the prior version, and they both fail to move files from cache to array.. In the logs it looks okay (it says X files remaining and X space remaining and it decreases etc.), but no files are actually moved. After disabling the plugin and running mover, it moves -- so the problem is the plugin. The cache is ZFS.

20 hours ago, CS01-HS said:

Is that expected?

Maybe because I have Clean empty folders: No ?

I can rule this out because I set it to Yes, reran, and the behavior persisted.

3 hours ago, zodihax said:

I'm on unraid 7 and tried both your newest version and the prior version, and they both fail to move files from cache to array.. In the logs it looks okay (it says X files remaining and X space remaining and it decreases etc.), but no files are actually moved. After disabling the plugin and running mover, it moves -- so the problem is the plugin. The cache is ZFS.

Do you have set Test mode = no? 

 

Edited February 15, 20251 yr by Masterwishx

3 hours ago, CS01-HS said:

I can rule this out because I set it to Yes, reran, and the behavior persisted.

It's only for MacOS or other smb too? 

2 hours ago, Masterwishx said:

It's only for MacOS or other smb too? 

 

Seems stat's Access is what macOS uses for Date Created and I don't see anything better so I assume it apples generally.

 

Here's an example:

 

Directory Where Eagles Dare (1968) was created on cache on 1/14

Mover runs on 2/13 at 02:24 and creates the directory on the array with a new Access time.

 

Files exist in both directories because I exclude specific file-types.

For reference: cache is BTRFS and the array is standard Unraid.

 

 

8 hours ago, CS01-HS said:

Seems stat's Access is what macOS uses for Date Created and I don't see anything better so I assume it apples generally.

I will check it but now I'm trying to fix issue with data moved that was ignored by folder in config. 

 

Mostly not sure if it's problem of plugin but something changed in bash or find function (like was fix from @DToX_) for spaces in shares. 

 

So we have some issues how find + bash working with parameters, if someone have experience in bash will be cool to check my dev github for `FINDSTR` in code... 

 

 

19 hours ago, Masterwishx said:

Do you have set Test mode = no? 

 

That's embarrassing.. no, it was on "yes", apparently that's the default when installing the plugin (and I removed and re-installed it several times).. Let me try again with test mode "no"

edit: haven't been able to test with a filled Cache yet (it's pretty much empty atm), but at least the rebalance shares option doesn't work, the find command must be wrong somehow.. (I can confirm that /mnt/disk5/system exists)
 

Feb 16 09:16:11 Tower move: Mover action: no action, only cache used (cache:only). Rebalance shares option is selected
Feb 16 09:16:11 Tower move: => Files detected in disk5 instead of cache. They will be rebalanced to cache
Feb 16 09:16:11 Tower move: find: '/mnt/*/system': No such file or directory

edit 2: didn't work now either, it just won't move files.. have to uninstall and rely on the "normal" mover (and yes, no "test mode == yes" this time

Edited February 16, 20251 yr by zodihax

On 2/14/2025 at 7:55 PM, Masterwishx said:

Without shedule mover will not run

Okay thanks.

 

But can you tell me why it dosent work?
 

 

43 minutes ago, DanielPT said:

Okay thanks.

 

But can you tell me why it dosent work?
 

 

Is your cache drive really over 95% full at this moment? Also, if its 95% full, moving until its 95% full is.... yeah

9 hours ago, Masterwishx said:

I will check it but now I'm trying to fix issue with data moved that was ignored by folder in config. 

 

Sure, no rush, I was more trying to determine if the problem was general or specific to me.

 

I've poked around and (this is only a first pass but) from what I can tell:

unRAID's mover calls the executable /usr/libexec/unraid/move

 

where age_mover uses rsync, with this call: rsync --archive --xattrs --relative --hard-links

which does not preserve atime.

 

Test:

root@NAS:~# touch /mnt/cache/Download/x
root@NAS:~# stat /mnt/user/Download/x
  File: /mnt/user/Download/x
  Size: 0         Blocks: 0          IO Block: 4096   regular empty file
Device: 0,46 Inode: 2744525     Links: 1
Access: (0666/-rw-rw-rw-)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2025-02-16 11:48:25.081690303 -0500
Modify: 2025-02-16 11:48:25.081690303 -0500
Change: 2025-02-16 11:48:25.081690303 -0500
Birth: -
root@NAS:~# rsync -v --archive --xattrs --hard-links --remove-source-files /mnt/cache/Download/x /mnt/user0/Download/x
sending incremental file list
x

sent 95 bytes  received 59 bytes  308.00 bytes/sec
total size is 0  speedup is 0.00
root@NAS:~# stat /mnt/user/Download/x
  File: /mnt/user/Download/x
  Size: 0         Blocks: 0          IO Block: 4096   regular empty file
Device: 0,46 Inode: 2744525     Links: 1
Access: (0666/-rw-rw-rw-)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2025-02-16 11:49:07.322278620 -0500
Modify: 2025-02-16 11:48:25.081690303 -0500
Change: 2025-02-16 11:49:07.323278611 -0500
Birth: -
root@NAS:~#

 

But by adding the --atimes option it will:

root@NAS:~# rm /mnt/user/Download/x
root@NAS:~# touch /mnt/cache/Download/x
root@NAS:~# stat /mnt/user/Download/x
  File: /mnt/user/Download/x
  Size: 0         Blocks: 0          IO Block: 4096   regular empty file
Device: 0,46 Inode: 2744526     Links: 1
Access: (0666/-rw-rw-rw-)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2025-02-16 11:51:47.631716978 -0500
Modify: 2025-02-16 11:51:47.631716978 -0500
Change: 2025-02-16 11:51:47.631716978 -0500
Birth: -
root@NAS:~# rsync -v --archive --xattrs --hard-links --remove-source-files --atimes /mnt/cache/Download/x /mnt/user0/Download/x
sending incremental file list
x

sent 100 bytes  received 59 bytes  318.00 bytes/sec
total size is 0  speedup is 0.00
root@NAS:~# stat /mnt/user/Download/x
  File: /mnt/user/Download/x
  Size: 0         Blocks: 0          IO Block: 4096   regular empty file
Device: 0,46 Inode: 2744526     Links: 1
Access: (0666/-rw-rw-rw-)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2025-02-16 11:51:47.000000000 -0500
Modify: 2025-02-16 11:51:47.631716978 -0500
Change: 2025-02-16 11:52:11.122488244 -0500
Birth: -
root@NAS:~#

 

But really, given all of mover's complexity (and my relative ignorance) that "mistake" seems too basic to be an oversight.

7 hours ago, DanielPT said:

But can you tell me why it dosent work

You can run it by move button 

7 hours ago, DanielPT said:

Okay thanks.

 

But can you tell me why it dosent work?
 

 

It should work when cache more that 95% by your settings

27 minutes ago, CS01-HS said:

where age_mover uses rsync, with this call: rsync --archive --xattrs --relative --hard-links

which does not preserve atime.

 

Sure i can add it ..

35 minutes ago, CS01-HS said:

Sure, no rush, I was more trying to determine if the problem was general or specific to me.

 

I've poked around and (this is only a first pass but) from what I can tell:

unRAID's mover calls the executable /usr/libexec/unraid/move

 

where age_mover uses rsync, with this call: rsync --archive --xattrs --relative --hard-links

which does not preserve atime.

 

Test:

root@NAS:~# touch /mnt/cache/Download/x
root@NAS:~# stat /mnt/user/Download/x
  File: /mnt/user/Download/x
  Size: 0         Blocks: 0          IO Block: 4096   regular empty file
Device: 0,46 Inode: 2744525     Links: 1
Access: (0666/-rw-rw-rw-)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2025-02-16 11:48:25.081690303 -0500
Modify: 2025-02-16 11:48:25.081690303 -0500
Change: 2025-02-16 11:48:25.081690303 -0500
Birth: -
root@NAS:~# rsync -v --archive --xattrs --hard-links --remove-source-files /mnt/cache/Download/x /mnt/user0/Download/x
sending incremental file list
x

sent 95 bytes  received 59 bytes  308.00 bytes/sec
total size is 0  speedup is 0.00
root@NAS:~# stat /mnt/user/Download/x
  File: /mnt/user/Download/x
  Size: 0         Blocks: 0          IO Block: 4096   regular empty file
Device: 0,46 Inode: 2744525     Links: 1
Access: (0666/-rw-rw-rw-)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2025-02-16 11:49:07.322278620 -0500
Modify: 2025-02-16 11:48:25.081690303 -0500
Change: 2025-02-16 11:49:07.323278611 -0500
Birth: -
root@NAS:~#

 

But by adding the --atimes option it will:

root@NAS:~# rm /mnt/user/Download/x
root@NAS:~# touch /mnt/cache/Download/x
root@NAS:~# stat /mnt/user/Download/x
  File: /mnt/user/Download/x
  Size: 0         Blocks: 0          IO Block: 4096   regular empty file
Device: 0,46 Inode: 2744526     Links: 1
Access: (0666/-rw-rw-rw-)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2025-02-16 11:51:47.631716978 -0500
Modify: 2025-02-16 11:51:47.631716978 -0500
Change: 2025-02-16 11:51:47.631716978 -0500
Birth: -
root@NAS:~# rsync -v --archive --xattrs --hard-links --remove-source-files --atimes /mnt/cache/Download/x /mnt/user0/Download/x
sending incremental file list
x

sent 100 bytes  received 59 bytes  318.00 bytes/sec
total size is 0  speedup is 0.00
root@NAS:~# stat /mnt/user/Download/x
  File: /mnt/user/Download/x
  Size: 0         Blocks: 0          IO Block: 4096   regular empty file
Device: 0,46 Inode: 2744526     Links: 1
Access: (0666/-rw-rw-rw-)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2025-02-16 11:51:47.000000000 -0500
Modify: 2025-02-16 11:51:47.631716978 -0500
Change: 2025-02-16 11:52:11.122488244 -0500
Birth: -
root@NAS:~#

 

But really, given all of mover's complexity (and my relative ignorance) that "mistake" seems too basic to be an oversight.

 

--arhive seems already have -times, also in code thre is `$MODIFICATIONTIME` so not sure what issue but will try to check ,it seems has a lot of issues to check ...

 

2 hours ago, Masterwishx said:

It should work when cache more that 95% by your settings

Again i really dont understand this? Why is it so diffrent from the last mover plugin?

This is a screenshot from the old mover

 

On 2/14/2025 at 4:58 PM, Masterwishx said:

No this should work, if you have zfs you need clean datasets option on

No I'm not using zfs. Tried running the mover again but same issue. Empty folders left behind after the mover has ran. 

Any ideas what might be causing it? Appreciate the help!

1 hour ago, DanielPT said:

This is a screenshot from the old mover

 

Do you mean mover 2023 version?

37 minutes ago, stephenjcarr2804 said:

Any ideas what might be causing it? Appreciate the help!

If you have set clean folders it should work, did you set test mode to No? 

12 hours ago, DanielPT said:

Okay thanks.

 

But can you tell me why it dosent work?
 

 

 

In that configuration, once a day at 8AM, it checks if the disk is >95% used, if yes it will move files older than 1 day, but only until it returns to the 95% threshold, so it wont move much unless the disk managed to get significantly higher than 95% in the time between scheduled runs. with a rule set like that I would be running hourly so the cache doesnt get a chance to overfill as it is checked more regularly.

 

so if it got to 97% it would move the oldest files, ignoring anything less than 1day old, until it got back to 95% then it waits for the next schedule.

 

I think the descriptions do need some updating, because the behaviour doesn’t quite match the wording.

 

if you want to clear out ALL files more than 1 day old you need to set the clear down number to 0% so it moves everything older than 1 day.

 

 

Edited February 16, 20251 yr by Faceman

2 hours ago, Masterwishx said:

If you have set clean folders it should work, did you set test mode to No? 

Hi 

test mode is set to no and Clean empty folders is set to yes. 
Just tried to run the mover again and same issue. The files move to the array, but the empty folders are left on the cache. 

On 2/12/2025 at 1:06 PM, Masterwishx said:

there is option days old

this doesnt work "right" on the new one.. i posted a few pages back on this one.  the old plugin could prefer age which is what i want.  i would like it to move files if it gets over 75% full or so... but I always want it to move files older than 10 days old to the raid.  i leave shows and stuff on the cache drive for 10 days so they start quick.  but after that i want them moved off so i normally dont have to worry about disk full percent at all... the old mover worked that way... this rewrite does not.  can we get that option? i saw simple mover had something that said prefer age or size... can we integrate that please?