So the "Protect missing drives" logic is not 100% at present and I can offer an "easy to replicate" failure mode.
1. On Linux (and probably on Mac) when you mount a drive instead of using a drive letter, you mount it to a directory in the filesystem (for this example, let's say I mount my samba share from my NAS at /mnt/media)
2. Once the remote drive is mounted at /mnt/media, if I point auto-import to the root of the mounted drive (/mnt/media/), JRiver will dutifully import everything.
3. However, if the remote drive becomes unmounted or otherwise can't be mounted, the directory I used as the mountpoint (/mnt/media) still exists as an empty directory in the filesystem!
4. If I do this on purpose (leave the drive unmounted and run auto-import), auto-import dumps the entire library even with "protect missing drives" enabled.
To be clear, I'm not sure how you would reliably and programmatically tell the difference between an actually empty directory and a mount point that isn't mounted. I'm not sure this is a JRiver issue per se, it's just the nature of how *nix filesystems work.
The workaround from the user side is to always point auto-import to a subdirectory on the mounted drive rather than the drive root (/mnt/media/Audio, etc.). If you do that the missing drive detection works correctly because when the drive goes away, while /mnt/media is still there as an empty directory /mnt/media/Audio is gone (and won't stat), so JRiver MC correctly detects that the drive is missing.
I'm not sure how this all plays out on Windows as I no longer maintain any Windows machines with JRiver, but I've seen a few similar reports trickle in from Windows users over the last few years so some version of this category of problem is still happening occasionally. Network drives behave in really unpredictable ways sometimes!
----
In terms of addressing the broader issue one way to help this is to change defaults (i.e. default fix missing links to "no"); another would be to find a way to call it to the user's attention when auto-import is about to dump a large number of files (kind of like the "are you sure" dialog that pops up for user initiated mass file deletions).
Coming at the problem a different way, another potential work around would be maintaining a relatively terse auto-import log that gets rotated on a schedule (like automatic library backups). One major problem I've had with troubleshooting these kinds of issues is that there's (I think?) no import logs kept unless you turn on debug logging for everything which is not suitable as a permanent solution (the log files fill up a lot of space quickly and get reset but not rotated so they're not very helpful in troubleshooting something that happened a day or two ago). Another problem with logging only when enabled is that users often don't know they have a problem because the issue only happens at odd intervals, and they find out about when it's already happened and then it's too late to log it!
What I'm proposing is something like automatic logging of auto-import activity. Something akin to the summary dialog that a user initiated import shows when it finishes, but logged on every auto-import to a log file that gets rotated on a schedule, so you can see, say, the last week's or month's auto-import activity easily. I've found that when something goofy happened with an auto-import (in the absence of logging), the easiest way to figure out what happened is often to roll back to a prior library backup and then manually run an import so I can see the post import summary to find out what happened. I'd much rather just be able to look at a log (or ask a user experiencing this problem to post a small log)!
Author
Topic: I've lost all the extra information in my database (Read 657 times)