sherpa
sherpa copied to clipboard
OneCDOnly
'Download' share is no longer created by QTS
I've been rather slow to realise the 'Download' shared folder that used to be created automatically on the default userdata volume, is no-longer created in the new QTS versions (I think it began with QTS 5.0.0). 😞
This is causing an issue for applications like SABnzbd and nzbToMedia that rely on this share to be present. Without it, a plain directory is created under [/share] - it's not a shared folder. So, it's not visible via File Station, or any existing share.
Still thinking how to solve this. Maybe SABnzbd and nzbToMedia QPKGs should check for a 'Download' share before starting?
Advice welcome.
Some more info: the above apps are affected as I've included /share/Download in the default configurations supplied with each QPKG.
I would use /share/Public/Downloads. It follows the Windows folder hierarchy (C:\Users\Public\Downloads\ or C:\Users\OneCDOnly\Downloads) and would integrate seamlessly into QTS.
AFAIK the Download share had the same access levels as Public so there shouldn't be a difference. Beside of that people should configure their NAS before putting data on it :)
Yep, I like the idea. It's only for default configs anyway. Once someone changes the location, they'll need to update all app configs to use the new path. 👍🏽
What if user has an older QTS version that does still create the Download share (and before that, it was called Qdownload). I can hear it now... "why don't you use the Download share as the default?" 😉
Can you check for the used QTS version? Depends if you want to do the extra work and ship the extra files :)
Extra work isn't an issue... but I must also consider what the "user experience" will be like, and not only during the package installation phase. 😉
Example: someone with a fresh NAS installs SABnzbd, nzbToMedia & SickGear. Their version of QTS supports a legacy Download share, so these 3 QPKGs decide to use the config files (or else have logic to modify the default config files) with /share/Download in them. Works fine so-far.
Sometime later, the user changes the location of their downloads for all 3 apps manually to be:
/share/MyStuff/InternetDownloads
... (or something equally unpredictable).
They then install Transmission, which - following the rules - chooses the /share/Download directory once again.
At this point, the user asks "why doesn't sherpa use the new location for Transmission too?" , then I have to explain that sherpa doesn't follow the configuration of each app, and actually has no-idea the user has changed the download path for each app to a new location.
Because I'd really rather not have to include code for a persistent configuration option for sherpa that records the path the user would like to use for downloads, as it's something the user must remember to update sherpa with. Sherpa would also need to be able to handle the transition from old to new path - migrating downloaded files as required in case user forgets. Then more persistent options would be required for temp files, incompletes, logs... it could get ugly very quickly. 🤣
So, I'm looking for a simple enough solution that will provide convenience for most cases, and is flexible enough for the power-users to modify as-needed without interfering with their changes.
Included a test for this when logging environment, so at-least we'll get an indication if Download is missing as a proper share.
I would use
/share/Public/Downloads. It follows the Windows folder hierarchy (C:\Users\Public\Downloads\ or C:\Users\OneCDOnly\Downloads) and would integrate seamlessly into QTS.
@an3k I'm going to proceed with this idea. I'll change the default paths in the various app config files to point to /share/Public/Downloads. This won't affect existing configs.
fixed in https://github.com/OneCDOnly/sherpa/commit/497b04db6cac058a1ac2909c5a5f11dc6ddf2272