NO! - I have my videofiles on the V-drive on all pc's because then projects are easy to move. I have the software on the C-drive in default folders. And the drive is is present and not asleep.
This type of upgrade has always worked flawlessly. There have been one previous install oddity with an accompanying program, but only in the first build of 17. And it is not the softwares business whether a datadrive is present - nor whether it is in-box, external or network - usually faster than external - it can always ask after the upgrade if in doubt. It is nowadays better to use a network-drive than to run simultaneous read and write on the same drive and it is twice as fast to use a network drive than to use a USB3 drive. When working with 4k it is a lost cause to try to keep all datafiles in the box, storage has to be flexible and structured. And the new build is complaining that a drive that IS available "does not exist".
Thank you, interesting story of quirks. It does however not seem to be to the point, build 421 is installed on this box and running and works fine, which it wouldn't if any of those causes applied. Also the box is only a few months old and capable and well working.
Checked to be overcomplete .net is activated. SMB1 was not, a known quirk that is sensible, but impractical with an xp-box still in use, fixed that, nice that it could be done without registry editing.
SMB is a double-bind for Microsoft. If they disable it by default some old organization like a financial institution, poorly funded healthcare or law enforcement organization will have antiquated "mission critical" applications that won't work after an upgrade. If the leave it on by default, every user in the known universe is exposed to exploitation even though few people absolutely, positively must use it.
True, on my previous day job I would have loved the disabling of it just to get a lower risk, but with windows breaking my preferred audio software I keep my xp-box runnable and I also need to have my NAS-drives mountable. However, let us not derail this …. I checked if there could be any pointer to drive V: in the current setup of 17 and I can not find any.
Anyway, just checked whether going via a new install download as if with a first time install would update properly, nah … same errornumber, -21 ….. a negative number to me suggests a numeric overflow. since it says it can not find an actually existing drive via its letter it seems to a an untrapped (do'h!) division by zero. It could have been a different install flow, but wasn't.
Hey MAAaAgIIIIIIixX … are you listening??? - seems like ya made a 4 am error! - checked whether the download was copied correctly to the magix downloads folder by the installer, no, it is not there. And that folder is in the My Documents folder, a relocateable systemfolder with a system variable pointing at it. And it is on drive V: because it is a mirrored drive in my local cloudserver. So now I know what is broken ….. btw. the error message refers to drive V: as drive V:\ - now that way of writing it refers not to the drive, but to the root directory of the drive …. ???
Leading to the question of whether the relocation string from the OS for the localized folder name "Dokumenter" is parsed incorrectly? - the answer is YES. Temporarily relocating the "My Documents" folder to default location fixed it. That makes it the second time I have found an OS stringparsing error in Vegas 17's install routine, there was also one - regarding Boris - in the initial release.
Note what is broken seems to be the move of the downloaded file to storage in the magix install folder in the My Documents folder, so it is the install that is broken also this time, someones understanding of windows needs enhancing, also the software testers so that they find such a fault.
Thank you Nick, it was the folder relocation that broke the move of the downloaded file by the installer to magix installs folder in My Documents as explained above, otherwise that file would have been needed, thoughtful of you!
The concept came into being because browsers used to be unable to resume a download if interrupted, I think it remained popular because it allows a fast initial download.
The windows operating system allows you to move the system folders, all of them actually as far as I know, including the My Documents folder to any folder with any name. This is because there is a system variable that points to the location you specify. The install program does not parse these system variables correct and thus having a relocated My Documents folder broke the install because the first thing the install program does after downloading is to move the file to install to a subfolder in the My Documents folder. Windows is a lot better and a lot more capable and a lot more configurable and much documented than many understand. All you need to pass a certification test is in the OS helpfiles. It is strongly adviced to simply read them. They are the user manual.
I'd say moving such folders is a bad idea. If you really need to release some space on your system drive and would like to move the content of such molders somewhere, you should use junctions instead.
My Windows Documents, Downloads, Music, Pictures & Videos folders have not been in the default location on my desktop or laptop PCs for many years. In fact I moved them the other day to be within my Dropbox folder, since I subscribed to the 2TB version of Dropbox. It's never been a problem but obviously they need moving via the right procedure.
On the occasions that I have installed a VEGAS product using a VEGAS "dlm" download manager, the installation has dealt fine with my Documents folder being at, for example, D:\Documents.
I'd say moving such folders is a bad idea. If you really need to release some space on your system drive and would like to move the content of such molders somewhere, you should use junctions instead.
As MCSE I disagree, the folder relocation is an essential part of the OS being network focused, to the local cloud they go so that the workstation can be freely replaced and formatted. As Nick says, it is usually unproblematic, with V17 installs, this is the second time it is has shown itself to be A problem, not for Vegas, but for the installation program.
On two systems that I "share" with my wife, I relocate the Desktop, Documents, etc. to another local disk. Doing so allows me to swap the boot systems without worrying about deleting any of her "stuff". Recently, I chose to undo that configuration long enough to build a VMWare virtual machine of our "office" PC, but put it back when I had a good VM. Some day, the system will break and it's so old the hardware won't be available. On editing machines, I leave user folders on C: but don't use them for anything. I've looked at junctions, but I have so many system images that implementing junctions would be more trouble than it's worth for a single user workstation. I find relocating these user folders useful for family members who perceive of me as their personal on-call hardware/software tech support person.
When a new release of Magix software is available, I usually download the full installation package without using download manager. if possible. If I have to use download manager, I watch where it downloads and move the installation file before I attempt to install Vegas.
I'd say moving such folders is a bad idea. If you really need to release some space on your system drive and would like to move the content of such molders somewhere, you should use junctions instead.
I do not want user data on the drive windows is on. I want to be able to format it with no data loss. Also, since this is the real world, this quite new box has windows on a SSD, at 1 terabyte it is way too small to have user data on anywat, so even IF they were not on my own local cloud, they would be relocated and it would be proper windows practice to so do. And this is a production computer, it is reasonably lean, it is not a "do all" box. Seems to me that you focus on my using the properties of the OS instead of on the documented error in the install program.
Thank you, the requester also said it in plain text, but nice to know another time, very useful, thank you! - The error was that there was no error handler displaying a requester saying that "i can't find your My Documents folder, where do you want the install archive placed?" - the underlying issue being that someone had not considered that a user might right click on the My Documents folder and ask for it to move somewhere more sensible than the drive with the OS on it. not even an advanced relocation via Active Directory. And it is 20 years ago that technology was implemented, so even that should be well known by now. Things happen, and it is NOT a Vegas error, it is an install program error.