jv6478

I decided to give this a try as I've been looking for a way to control certain fans based on GPU temp. I'm happy to report it works without any problems, and I'm on 7.2.0. I followed the instructions fully. I haven't added the auto-start line to the go file just yet -- do any of these changes impact the typical behavior of the auto-start? As it was before, all plugins, including Auto Fan Control, would auto-start on Array start already. Otherwise, this is a great feature to have, and thank you for making it work!

This is how I understood it as well, and I feel like it's useful for something like that, but not for the granular control that I'm looking for. That's right, and it wouldn't address my particular case as you mentioned. I tested on my end with a custom rsync script, bypassing the internal mover process, and it works exactly as I intend it when ignoring a file that contains a hardlink. It moves what it finds as I need and expect. I haven't tested with the --hard-link flag, but I presume it wouldn't make a difference in my case because I'm excluding hidden folders before anything is scanned. That's important to be able to make it an option - ensuring there is no passing of hardlinked files to the instruction before rsync scans (this is kind of a double check, where if rsync's scan doesn't find the expected files based on the initial list that's created, it will skip the file). Because I excluded the location where the hardlink resides, rsync moved the file in /media normally because it didn't find a hardlink at all. This means, whatever mechanism (find, etc.) is building a list before the rsync command, needs to be edited to include the exclusions based on the options selected in the plugin (hidden folders, exclusion list, etc.) so the list is built without those files and rsync doesn't see a mismatch when processing. I think this is the key.

Exactly! You've got it. Essentially, the option could be something like this: ====== Always break hardlinks to move files if necessary WARNING: setting to 'Yes' may result in multiple copies of the same file, i.e. two copies of the same file in different paths on the array, or one copy on cache and one copy on array of the same file (this may be useful for cache seeding). You will know if you want this option - most people will keep this set to 'No' (default) which will: - identify hardlinks - preserve/recreate hardlinks as they were - prevent multiple copies of the same file on the same drive ====== 'No' would be default, how the mover runs (or is intended to run) currently. 'Yes' would need to do three things. 1) remove the --hard-link flag (this is a good safety measure, although it shouldn't make a difference, this should help ensure no edge case where multiple copies of the same file is created on the destination drive); and 2) remove at least the log output from this chunk: But this is only for the log output to not be confusing if someone has set to 'No' - this would not change the functionality. This brings us to 3) the change would have to lie in a different place. It is likely that there is a find command or something else happening that is building a file list, including all hardlinks and inode info, before rsync with chosen exclusions, such as hidden folders or an exclusion list, scans and runs. Normally, rsync on its own does not scan excluded folders, so it wouldn't even find a hardlink in .downloads to skip it because it's also in media/*, it would just process it like a normal file. It would have to have gotten the info elsewhere to see a mismatch before moving, so it skips the file because of that. This is the kicker, and this is what would have to be changed or allowed somehow, if this option were to be possible. I can try to explain it differently or with different examples but I hope that is making a bit more sense now from my end. It's challenging to communicate it.

That check would be necessary if hardlinks are to be moved/preserved together, which would then work in conjunction with --hard-links so only one copy of the file is moved and the links are preserved as they were (they're rebuilt essentially, as @ronia wants basically). Hypothetically, if there were an option in the UI to always move all hardlinks, this check and the --hard-links would have to remain in place. Without --hard-links, rsync would create n copies of the file (where n = number of hardlinks), one for each location of the original hardlinks, which is not ideal and takes up much more space on the destination drive. That said, --hard-links would not prevent the breaking of a hardlink to be moved if it's changing filesystems and has no choice anyway. The key thing is to not build the list in such a way that rsync ignores hardlinked files if someone chooses this (i.e. an option). Further to this... My setup is as follows (I think many people have similar setups, though it can also just be preference apart from this): 1. download directly to /mnt/cache/media/.downloads (media = share) 2. *arr will hardlink completed downloads to /media/* on cache - many downloads are watched within a few days, so it's nice for those to be on cache before it's archived onto the array 3. Mover will move /media from cache to array, but not touch anything in /.downloads (I have set the option to ignore hidden files/folders) so seeding can continue and finish off of cache, as I do not want anything seeding off the array << at this point, it would be detected that this is a hardlink -- move it anyway -- this would break the hardlink, of course, because it would no longer be in /mnt/cache/media/* as it would make a copy of the file on /mnt/user/media/* (array) (or /mnt/user0/media/* I suppose), and then delete the hardlink from /mnt/cache/media/* 4. The file, now the only copy left on cache (in /.downloads), would continue seeding until finished, at which point the download client will remove the original file, leaving no file (or hardlinks) on cache As you can see, in this case, the hardlink must "be broken" for my setup to work, unless I set a delay to always make sure that only files over a certain age (longer than the seeding requirement) be moved. The space on cache would not be reclaimed right away in this case, but it allows the file to be archived when I want, and avoids stale media files staying on cache after the seeding is complete before the next mover runs. By default, rsync will break hardlinks, unless told otherwise. This is the part that would be nice to be user-configurable. Hopefully that didn't complicate things further LOL!

Ah okay, I understand. Yes, it should be moving both as you mentioned in that example for sure, as long as the destination is the same file system. It should essentially move one file (as far as amount of data it's moving) and then recreate the links in the same structure on the new drive. This could be a different (but related) problem. In my case, if data is the share, and torrents is the downloads folder, I would have it as /mnt/cache/data/.torrents (hidden) as I don't want torrents to be its own share. I've also selected the option to ignore hidden files and folders. It seems to work as it doesn't descend into those. However, if an *arr app hardlinks from /.torrents to /data/tv/* (which it regularly does) and mover tries to move that file, I'm getting the same error messages saying that "x files expected" ending with not moving the file to prevent breaking hardlinks. If --hard-link is used in the plugin, rsync will want (or need?) to move both files. Whether this causes a skip, or it skips because it simply doesn't "see" the hardlink in the /.torrents folder, I'm not sure. But this creates a "hole" in the plugin options, while trying to force one specific action (move hardlinks all the time) instead of having an option (break hardlinks if I'm okay with it). This situation illustrates the need for it to be an option. It would also have to somehow play nicely with the ignore hidden folders option, as if a hardlink is there, there has to be a way to decide what to do. Perhaps a nested setting; if ignore hidden files and folders is selected AND move all hardlinks is selected, a hardlink found in a hidden folder WILL or WILL NOT be moved (another toggle). The logic around this is just a concept, but it would have to be something along these lines I suppose. Some people will want all hardlinks to be moved, and some people will want them to be broken. I don't think either is right or wrong, but the plugin trying to force all hardlinks to be moved doesn't feel like a solution, rather a choice, that can hopefully made to be our choice somehow. For now, I've customized the mover script to do what I need - i.e. break hardlinks and move the files - and it's working very well although it still calls on the internal move command. I prefer rsync for various reasons, and really hope I can make use of this awesome plugin again sometime soon.

Do you mean that it would preserve the original file that was hardlinked before the move? If so, then that's what I meant as well. By breaking the hardlink I was referring to allowing the mover to move the file despite the fact that it has a hardlink. I may have been off with the term though, sorry if so! I'm getting the same messages in my logs as you are in a hardlink scenario, and it sounds like you want it moved but for it to preserve the other links that would be left on cache. I want the same.

I'm experiencing the same thing. My setup relies on these links breaking, as the official mover seems to be able to do. Would it be possible to make this a toggle in the UI? I think the plugin used to break hardlinks up until a little while ago (not sure exactly why it was changed/patched out). I feel like this would be best as an option depending on different setups, and not seen as a bug or issue. Thank you for the work to maintain and update the plugin!

In the active File Activity log, I just see that a file was opened but I'm trying to track down what actually opened or accessed it. If that's something I can find, where would I look? Thanks for your support!

Hey all! Great plugin and thank you for your time. I'm wondering if the plugin logs previously-opened files. I used File Activity and realized that one of my movie files was opened. Almost exactly 30 mins (my spin-down setting) after, the related disk spun down. This suggests the file was kept open for a short period of time, I think. When checking Open Files, I wasn't able to see that file shown as open. This may be because it was open for a short time and I missed it. To confirm if that is the case, I'm wondering if there is a log that shows some history that can be accessed. Thanks in advance!