And it works no problem (I see the directories listed as drives in the folder tree etc), but sometimes, when I try to do an operation on certain files - copy, move etc; DOpus reports that it can't find the file eventhough I can see it in the lister in front of me?
Removing the .bat file makes it all work normally again.
I'm using Vista, Not Windows 7, but I do know of a simple trick that does works on Vista.
Try this:
Write your batch file containing all the DOS Subst commands.
Save the bat file to a New Folder on your Operating System Drive ( C:),
but NOT the Windows 7 Startup Folder.
Make a shortcut to the bat file.
Edit the properties of the shortcut and choose from the Run dropdown menu,
Run as Minimized.
This will cause a brief flash on your taskbar on startup, but NO ugly DOS Window.
Move the shortcut to your Windows 7 Startup Folder.
Restart your computer.
This Does work on Vista. I must admit I find the ancient DOS Subst coomand quite archaic.
I'd prefer a better modern solution, but I don't have a good answer to this.
If this does work on Windows 7, other improvements if the drive mounts at startup, are possible using junctions .
The subst-drives won't be there, but the folder(s) that the mapping was pointing to is still here, on my external HD.
So when I remove the bat file, restart the computer (or just delete a Subst-assigned drive letter through VisualSubst) and perform whatever operations on the files it works normally without reporting non-existing files.
Example
There's a file - T:X/Games/BananaNababa/BananaNababa.exe. Now I run a "Subst X: T:\X" and in the Folder Tree a new drive letter will appear (X:). Clicking on it shows a folder "Games" in the lister's tab. A few more clicks and I end up in the directory where the "BananaNababa.exe" (and some other files) is. So far so good. But, doubleclicking on the "BananaNababa.exe" just returns a standard "file doesn't exist" kind of message.
Now back in the folder tree, clicking on "T:" drive and all the way down to "BananaNababa.exe" runs the game without problems... No error messages whatsoever.
Same kind of problem appears with ProcessMonitor for example. Other files can't be copied, or moved etc. I also can't change owners / permissions of the files ("The system can not find the path specified"). I can change the owners / permissions but they do not get saved properly if this means anything.
I have only one external drive that I map all the letters to, haven't tried with other drives.
First the UAC window appears ("Do you want to allow the following program to make changes to your computer?" - can't screenshot it because Alt-PrtScreen stops working when the message appears), and then a standard sounding "can't find" message (attached).
Just tried it - same thing. Sorry for not trying it earlier, I forgot Explorer even exists after using DOpus for so long. I guess this means it's not tied to DOpus after all.
[quote="Scred"]I'm using Vista, Not Windows 7, but I do know of a simple trick that does works on Vista.
Try this:
Write your batch file containing all the DOS Subst commands.
Save the bat file to a New Folder on your Operating System Drive ( C:),
but NOT the Windows 7 Startup Folder.
Make a shortcut to the bat file.
Edit the properties of the shortcut and choose from the Run dropdown menu,
Run as Minimized.
This will cause a brief flash on your taskbar on startup, but NO ugly DOS Window.
Move the shortcut to your Windows 7 Startup Folder.
Restart your computer.
This Does work on Vista. I must admit I find the ancient DOS Subst coomand quite archaic.
I'd prefer a better modern solution, but I don't have a good answer to this.
If this does work on Windows 7, other improvements if the drive mounts at startup, are possible using junctions .[/quote]
Actually I had it like this (with the shortcut instead of the actual file, only I didn't have it set as "Run as Minimized" but it shouldn't make a difference) before, but it behaved the same. Yes, I'm using Windows 7 Home Ultimate (?), will investigate junctions further, thanks for the hint.
I'm still confused over the "Removing the .bat file makes it all work normally again." comment, are you saying that everything works if you "manually" subst map the drives as opposed to having the batch file map them for you at startup?
I'm asking so as to see if there's some rhyme or reason that we can attribute to the SUBST'd drive flaking out on you... I'm wondering if any of the following makes sense:
a.) if it ONLY sometimes breaks immediately after startup - is there some sort of strange timing issue with the external drive becoming available vs whenever the SUBST commands run? I know - it sounds off-base since the SUBST mapping would otherwise SEEM to be valid - since you're saying you can clearly BROWSE the mapped drive and SEE the contents, just not copy, execute or otherwise interact with the files...
b.) if you immediately remove the SUBST mapping after you encounter the issue, then access the same file through the REAL folder path... if you then RE-ESTABLISH the SUBST drive mapping to the folder, does it start working again? If no, does it change behavior if you re-subst the folder to a DIFFERENT drive letter that you don't normally use? Again, they key is first getting it to work through the REAL path - i.e. you might be "waking" up the external drive?
Even if I don't subst the drives at the startup but do it manually after boot instead (->cmd, type "Subst X: T:\X") the result is the same. Attempting to launch the same software through T: works and does not ask about permissions, but the same thing doesn't work if I try to execute it through the newly assigned X: . Weirdly I can read the file: for example if I "Open it with..." -> "Notepad++" then Notepad++ actually opens the file.
Some files are flaky sometimes (newer ones, which I'm creating dialy) but old files (that were on the HD before I mounted it on my Windows 7 computer) always behave the same, ie I can't run the aforementioned BananaNababa.exe through the subst-ituted path (in my case X:) no matter what. But - I did notice my HD is sometimes slow to pick up (I know because I see it on my desk and sometimes it takes a whole second or two before it starts loading a file for example). I guess this isn't related since if I remove the subst-ituted drives it all works normally except for this annoying lag.
Just tried it, and it doesn't help, but. Waking up of the drive does have an effect on saving files, loading and showing directories in Opus though, for example if I don't use the drive for a long time and then start reusing it again the first time Opus shows the blue rotating snake thingy... but after a second or two it always works. Executing a file through the real path always works, while certain files can't be executed through subst-paths no matter what it seems.
Assigning it to a different letter actually works! But. The problem is, all the files I have from the previous computer rely on linked files from P:, so I need it to be mapped correctly (also I mapped them in a way that's easy to remember - P for projects, R for reference etc and it'd be neat ifI could keep it like that)... Otherwise I'll be relinking files for the next few weeks. Still, this is progress, at least it works.
One weird thing I noticed is that some of the files and directories have the Windows 7 "locked" icon, some don't - it's all mixed up, while in the Properties -> Security there's a weird account that I never created (something like ??-qq2414213415) listed together with System, Admin and User.
(btw I guess this whole thread turned out not to be a problem with Opus at all, so maybe a mod should move it out of the way to a more appropriate subforum?)
After lots of combing of the internet, I got the idea of running the batch script that assigns the drives twice, once as the User and once with Administrator rights (Right click -> Run as Admin). All my problems are magically gone! (at least the ones caused by Windows and Subst :^)
Apparently this is because Subst creates the substs only for the user that executes the script, not for everybody (and by default I was in "User" mode) - so when a software wants to do something that requires Admin rights, it refers to a non existing path... sorry for my amateurish explanation.
It turns out it wasn't a DOpus problem at all - still, I thought to report it in case anybody else has the same problem and stumbles upon this later.