Problem with VMS_SUPPORT.C
I've been trying out the 2.2.7A kit on OpenVMS 7.3-1, and I've noticed a problem I don't think I've seen mentioned here. In the log.* file, I noticed there was a $GETDVI error after every file accessed. So I looked around the source for where it came from, and I see that the system call isn't coded properly in VMS_SUPPORT.C sts = sys$getdvi(0,0,dev,dvi_itm,iosb,0,0,0); I think should be sts = sys$getdviw(0,0,dev,dvi_itm,iosb,0,0,0); The wait version should be used to make sure the information comes back before the program proceeds to use it. Also, I think the addressing mode on the I/O status block was wrong. (I'm also not thrilled with the declaration of iosb, but that's a separate issue.) However, this doesn't fix the underlying problem. If you look at the error code, it translates to invalid device name. If you look at where dev is filled in, it calls vms_get_filespec, which includes an entire file name specification. I checked the manual, and the item codes being requested for GETDVI, MAXBLOCKS, FREEBLOCKS, and MAXFILES, apply only to devices, and not files. (Actually, I believe all of GETDVI applies only to devices and not files.) So before calling GETDVI you need to strip off everything but the device specification. Even so, this code doesn't make obvious sense to me. Why would you need to retrieve this information when reading files? I can see wanting to know how much free space remains on the disk before trying to WRITE a file, but none of this is needed when reading a file, and only FREEBLOCKS is of any use in telling you if there is sufficient space to write a new file. It seems to me that SAMBA is doing a lot of unnecessary work here. Suggestions? Bart. PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
RE: Problem with VMS_SUPPORT.C
The $GETDVI call is in vms_statfs, whose job it is to return info about the file system; in VMS, the disk. When this procedure gets called is ultimately the choice of SAMBA, not the VMS support extensions. Perhaps John could chime in here with some background on the uglies of SAMBA. :) The call to vms_get_filespec translates a Unix formatted path *relative to the share mount point* (e.g. .) into a VMS formatted one (e.g. SYS$COMMON:[TNT.CLIENT], if this is the mount point, for .). $GETDVI is a pretty flexible beast. It will or will not do logical name translation depending upon whether the first character of the dev argument starts with an _. ($18$DKA0:[SYS0.SYSCOMMON.TNT.CLIENT]) Either way, if the specification includes a :, that character and all following are disregarded ($18$DKA0). The passing of the iosb argument is legit. This is syntax sugar for arrays, where referring to the whole array without brackets in the procedure call yields the starting address of the first element. Had iosb been declared as a struct, the iosb reference would have been required. All that said, I believe you're right with the need for $GETDVIW instead of $GETDVI. Now, back to your errors. What is the argument for device name that it is having a problem with? I wonder if we are actually seeing the error from the previous call given that we are not using the synchronous version. A controlled run with debug level three might be helpful here. Peter -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of B. Z. Lederman Sent: Wednesday, March 26, 2003 8:42 AM To: [EMAIL PROTECTED] Subject: Problem with VMS_SUPPORT.C I've been trying out the 2.2.7A kit on OpenVMS 7.3-1, and I've noticed a problem I don't think I've seen mentioned here. In the log.* file, I noticed there was a $GETDVI error after every file accessed. So I looked around the source for where it came from, and I see that the system call isn't coded properly in VMS_SUPPORT.C sts = sys$getdvi(0,0,dev,dvi_itm,iosb,0,0,0); I think should be sts = sys$getdviw(0,0,dev,dvi_itm,iosb,0,0,0); The wait version should be used to make sure the information comes back before the program proceeds to use it. Also, I think the addressing mode on the I/O status block was wrong. (I'm also not thrilled with the declaration of iosb, but that's a separate issue.) However, this doesn't fix the underlying problem. If you look at the error code, it translates to invalid device name. If you look at where dev is filled in, it calls vms_get_filespec, which includes an entire file name specification. I checked the manual, and the item codes being requested for GETDVI, MAXBLOCKS, FREEBLOCKS, and MAXFILES, apply only to devices, and not files. (Actually, I believe all of GETDVI applies only to devices and not files.) So before calling GETDVI you need to strip off everything but the device specification. Even so, this code doesn't make obvious sense to me. Why would you need to retrieve this information when reading files? I can see wanting to know how much free space remains on the disk before trying to WRITE a file, but none of this is needed when reading a file, and only FREEBLOCKS is of any use in telling you if there is sufficient space to write a new file. It seems to me that SAMBA is doing a lot of unnecessary work here. Suggestions? Bart. PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Problem with VMS_SUPPORT.C
In case it wasn't clear, I'm still seeing erros after changing the call to what I posted in my first message: sys$getdviw and the correct addressing mode. The error message passed back says it's trying to do a GETDVI with a device name that in fact contains a file specification string. It should be just a device name without any file or directory information. This has absolutely nothing to do with logical names. A GETDVI call has to be fed a device name only. The code clearly indicates that it's being fed a file specification. I don't see how this call could ever have worked properly. PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
RE: Problem with VMS_SUPPORT.C
Please check the doc for $GETDVI (http://h71000.www7.hp.com/doc/731FINAL/4527/4527pro_053.html#jun_285) which described the common arguments common with $GETDVIW. You'll see in the description of the devnam argument how information additional to the device name may be supplied. $GETDVI has no requirement of being fed a device name only. Also, I don't believe the iosb reference in the call needed correcting, due to C language standards for array references. It would be interesting to know what was reported in the error message about the name being tested with $GETDVIW to see how the relative path ended up getting translated into a absolute VMS path. Knowing the specification of the share in the smb.conf would be helpful too. We won't know what kind of problem you are having until we see the full error message reported. Peter -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of B. Z. Lederman Sent: Wednesday, March 26, 2003 12:19 PM To: [EMAIL PROTECTED] Subject: Re: Problem with VMS_SUPPORT.C In case it wasn't clear, I'm still seeing erros after changing the call to what I posted in my first message: sys$getdviw and the correct addressing mode. The error message passed back says it's trying to do a GETDVI with a device name that in fact contains a file specification string. It should be just a device name without any file or directory information. This has absolutely nothing to do with logical names. A GETDVI call has to be fed a device name only. The code clearly indicates that it's being fed a file specification. I don't see how this call could ever have worked properly. PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Please do not send out-of-office reports to postings.
Folks, If you are using and out-of-office or vacation notice program on your e-mail program, please set it so that it does not respond to mailing list e-mails. There should be a setting for this, as mailing list e-mails have special codes in their headers to identify them. Contact your e-mail administrator if you need help on this. Also be aware that at least one convicted criminal has stated in interviews that he and others use out-of-office notices from e-mail and voice mail to locate targets for identity theft. This method was used to steal from many companies before this person was caught and is still being used by other criminals. So sending an out-of-office message to unknown people is not a good idea for your personal or company security. A voicemail message can give an alternate contact, but should not let out information to a criminal to know that you are not going to be around for a while. On a U.S.network TV show a few years back, it was demonstrated to a company by a security specialist that just by using a phone and calling until they got an out-of-office voice mail they were able to obtain the dial in number to the computer network, and got an account name from the help desk and the password reset. -John [EMAIL PROTECTED] Personal Opinion Only PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
