(Illustration by Gaich Muramatsu)
(Illustration by Gaich Muramatsu)
Check the DOS Windows settings of Venus . The check box in Properties - > Misc - > Termination must be unticked.
Boot your System in DOS mode by pressing F8 on boot time. Cd to the Windows directory and type edit system.ini . In the section [enh386] you will find following entries:
device=c:\usr\coda\bin\mmap.vxd device=c:\usr\coda\bin\mcstub.vxdComment them out by using a ; in front of the lines. Try to restart Windows again.
See Section 8.2 . When this happens it might not be possible to restart Venus, if it is still mounted. In this case try to unmount by typing unmount drive . If it does not work, you want to reboot the machine.
Look in the file c:\vxd.log . The file system driver codadev.vxd prints information about all requests and answers in this file. the information is only stored if the debug level has been turned on. the debug level is specified in the registry key HKLM/System/CurrentControlSet/Services/VxD/Codadev/Debuglevel . Set the debug level higher than 0 to receive messages in the debug file.
Venus switches to disconnected mode after a short timeout. After that it should work fine. If it doesn't, check if you have 'network connections' set up in the explorer (e.g. windows shares). Sharing such a network drive blocks your system when no network is available because the SMB filesystem doesn't handle disconnected operations.
Most command line tools, that talk to Venus through the ioctl interface of the Coda kernel module seem to work even when they print error messages.
Handling large files (in particular executables) does not work well in a low bandwidth scenario.
cfs.exe and hoard.exe use absolute pathnames so far.
Short filenames are not supported under DOS environment yet. You can access files, but you need to use the long filenames. Or was that the other way around?