Uninstall doesn't remove ChannelsDVRdata (synology dsm6)

I am sure this is probably known already

I note that on removal of the DSM6 package (that i installed way-back-when(TM)) it didn't remove the /volume1/ChannelsDVRdata directory

not a big issue as I can rm -r it - however as the directory is not surfaced in the synology UI at all (at least not with the version i installed, i note on my new DSM7 unit it is displayed) it might confused some non-ssh using users to be confused why their storage isn't as empty as they expect...

Removing a Channels DVR DSM package will never delete a user data directory.

Problem is the old DSM 6 package didn't create a shared folder as a default location, but the new DSM 7 packagage does. The new DSM 7 package also runs as System Internal User channels, where the old DSM 6 package ran as root.

Been discussed in a lot of topics here.
They need to update their Install Notes on their website or keep answering these type of questions.

1 Like

agreed, the backup / restore note is also one that needs a lot of work....

Your use case was a bit out of the norm, though. Backups tend to preserve creation dates, but your network file transfers did not.

I think the issue is more with your use of network storage locations, and transferring to a different location. (And remember that network storage is never recommended for DVR/TV usage.)

However, your particular case does raise the issue that their file selector for the restore process only looks at the file creation date, and not the backup's internal date, nor the folder's name with a timestamp embedded.)

Apologies, I think I might have confused you, I don’t use network storage locations. I use local volumes on the NAS.

The documentation broadly says transfer your files. I didn’t have a USB drive to hand and decided to copy the files over the network from NAS A to NAS B.

Had I used a USB drive as per the docs the situation would have been identical.
A) the symlinks issue would have been the same
B) the file creation dates would still not have been preserved

I believe the only approach to A might be to tar the whole structure.
I don’t know a solution to B

Either way the docs and process are not user friendly at best and utterly misleading at worst. A better feature would be to point NAS B at NAS A and say ‘migrate content’ and it just work.