I have to use subst drives alot, and when a file changes (including when created or deleted) in a directory on a subst drive, this change is not seen until the view is refreshed.
It appears to work ok in Explorer and the directory listings are updated without the manual refresh.
I have also tried "net use z: \127.0.0.1\drivename" instead of subst-ing, this also works but creates a few other probs with our novel network and I have had to go back to substs.
It might be worth trying the debug stuff in this FAQ but I'm guessing that subst drives are like NTFS junction points to Opus: The system will be reporting changes to the real path and Opus doesn't know they apply to the path it's looking at as well.
I'm guessing you need to use the subst drives for another program and you're not using them purely as an organisational shortcut. Opus aliases are not visible to other programs but they may provide an alternative to subst drives if you're only using them as shortcuts for file management.
The Windows Subst command is used to create a virtual drive.
Virtual drives are in essence a root alias to a much deeper folder path. They are very useful for software testing, or the like, where one may want to simulate the root of a hard drive partition without actually creating a partition.
These virtual drives are not junction points, nor are they mapped network drives. Virtual drives function nearly the same as a mapped network drive, although they will not appear on the list of drives under the Net Use command. They may be assigned to: a local path, a path on a removable storage media, or a network path (on a mapped drive or a UNC path). Whichever type of path a virtual drive is assigned (hard disk drive, network, removable storage) path, it will appear in My Computer under that type of drive. Virtual drives assigned by the Subst command do not live past the current Windows user logging out.
The output of a net use command will not display a virtual drive. However, the output of fsutil fsinfo drivetype and fsutil fsinfo drives will list information about virtual drives as if they were real drives.
Below is a snippet of one my issues, that I'm still in the process of editing for the BBT list:
The DOpus Raw command: "Clipboard COPYNAMES=unc" will not work when a shared network drive has been assigned a drive letter using the SUBST command, rather than using the Net Use command (or Map Network drive). The command: "Clipboard COPYNAMES=unc" works well for mapped network drives, and when listing a UNC path. However, a network drive could be assigned a letter via the SUBST command rather than mapped via the NET USE command (Type "SUBST /?" at the Windows XP Command Prompt for more information.
The above behavior seems to suggest that Opus treats all virtual drives as local drives, not network drives.
Agreed, subst drives are very differnet to junction points, but my guess is that Opus doesn't detect changes on subst drives for the same reason it doesn't detect changes through junction points: Because the OS reports the changes for a different path and Opus doesn't (currently) realise the path relates to what it's looking at.
I just used subst to assign a virtual drive (Q:) along on a path that resides on a shared volume of a networked computer (workgroup not domain). Then I opened a command prompt and typed the following:
Dir /s C:\ > Q:\Dir.txt
This command will slowly crawl my 15 GB system partition and create about a 3 MB complete file listing of my C:\ volume on the root of Q: (my virtual drive). This speed allows me to watch the file size and the Modified Date and Time Stamp progress in Opus.
The file named showed up immediately in Opus, the file size grew incrementally (about every 20-60 KB or about every 2 seconds) as the command prompt continued to redirect output to the file. Initially the MD5 Checksum displayed File to large, but once the file was completed the checksum also finally appeared. I got the same results (though much faster) when I used subst to assign a virtual drive to a path on one of my local hard disk drives. So Opus does pick up changes from the operating system on a subst volume (network or local at least).
But all this being said, there are frequent reports (and I seen it myself a hundred times) that Opus does not always pick up external file and folder changes. Currently, I do not believe there is a single common reason for every occurrence of this phenomenon (at least not enough for me to type up a decent issue report yet), but the issue does exist. However, I do not believe it lies within the Subst command itself, or in Opus' ability to specifically pick up changes to a virtual drive (created by subst).
Just out of curiosity, are you using a USB drive?
On second thought, his underlying path seems to be a network drive, and a Novell one at that. I wonder if there is a similar network polling issue for Novell as with Samba? It would not surprise me, knowing how well Microsoft plays well with others.
(My test was in a Windows Workgroup between to Windows XP machines.)
Can you try my test steps above and post your results here?
I am using a Compaq nc6220, XP Pro sp2, 55GB HDD, 1GB ram
on a novell network
The subst drive is local, on the c drive. I tried the 'net use' as an alternative to subst-ing, which worked but created issues when connecting and disconnecting from the novell network.
I tried the 'Dir /s c:\ > q:\dir.txt' and didnt see any sign of the output file until I hit refresh.
Can you try the same test with Windows Explorer and tell us what the results are?
Using Explorer, tried 'dir /s c:\ > q:\dir.txt'.
the output file appeared immediately and the file size was updated approx every two seconds.
Just tried the same thing with the output file on a real network drive.
Didnt see the file creation the same as a subst drive until i hit the refresh.
I checked that the 'Detect external file changes on network drives' was still selected and it was.
And another thing,
I had a look in the Opus debug window, notifications are there for the files as i change them, but they are listed with the full c:\ drive path and not relative to the subst drive.
Out of curiosity... what sort of problems were you seeing related to being on a NetWare network when trying to 'net use' to a local folder? Some sort of conflict with the 'first network' drive letter value in the Novell Client I presume?
I'm sorry, but I'm plum out of ideas here. It's working fine on my setup, and I cannot recreate your issue. That is the strange part, why is working for me and not for you? The only difference that jumps out at me is your network type. I'm using Microsoft Windows Network, and you are using Novell.
I tried the same test on an xp pc on a microsoft network and it worked. Also tried it from another machine on the same network, and it worked. Connected my laptop (the one usually on the novell network) to the ms network and it didnt work. I'd like to uninstall the novell drivers and try it again - but I'm not. I'm sure its not the fault of DOpus, but more a XP/novell interaction. So now I'm going to give up and press F5 alot.
Thanks for your time
Issues like this is why companies take Microsoft to court.
I noticed yesterday that file changes are now being displayed on the subst drives. Nothing has changed on my pc apart from all of the microsoft updates being installed this week. I dont remember seeing them actually fix something before. It must have been your last post that nudged them into action.
Oh how I wish I wielded that much influence with large software companies...the software features we would would see and the crap we wouldn't see