RE : RE : Problem with VMS_SUPPORT.C
John Malmberg wrote: > Unfortunately this is the wrong thing to do when their are multiple > users accessing the file. If one of them modifies the file on purpose, > that modification date gets lost. Yes, that is true. > Either pure RMS or ACP calls need to be used, or an extension is needed > for the C RTL. The extension would be to allow XABs to be added on to a > file open request. I do not understand what you mean by this. Currently, the Samba routine that restores the modification date after a Read/write open and no changes of the file uses an ACP call, but it's probably not your point. In my understanding, the problem happens when : - Samba opens a file in read/write mode - Somebody else (let's name him X) opens the file in read/write mode too. Note that X is not another Samba, because the Samba locks would prevent that. - X modifies the file and closes it : the modif date is changed, for a good reason, - Samba then closes the file, with no changes done, and restores the original modif date, and that's bad. The best idea I have is to check, just before restoring the date, that the modif date is still identical to the one we got at open time, but even this is not 100% sure. You have probably a better idea, so please tell me. PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
RE : Problem with VMS_SUPPORT.C
COLLOT Jean-Yves wrote: > John Malmberg wrote: These open/writes should not update the file modification dates. The only way I see around this is to track to see if the file was actually modified and then use the XQP function to restore the dates to what they were when the file was opened. I completely agree. That's exactly what the last Samba/VMS version does. Unfortunately this is the wrong thing to do when their are multiple users accessing the file. If one of them modifies the file on purpose, that modification date gets lost. Either pure RMS or ACP calls need to be used, or an extension is needed for the C RTL. The extension would be to allow XABs to be added on to a file open request. -John [EMAIL PROTECTED] Personal Opinion Only PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
RE : RE : Problem with VMS_SUPPORT.C
> These open/writes should not update the file modification dates. The > only way I see around this is to track to see if the file was actually > modified and then use the XQP function to restore the dates to what they > were when the file was opened. I completely agree. That's exactly what the last Samba/VMS version does. PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
RE : Problem with VMS_SUPPORT.C
>The error is in what ever routine is converting UNIX filenames to VMS. >It is setting the ":" as a filename character, and not as a device >delimiter. It's the sort of thing that decc$to_vms might be provoked into if DECC$FILENAME_UNIX_ONLY were set. I suspect folks will be in for a whole heap of grief, if these things start getting set system wide, however backwards compatible the defaults are. This is only speculation though; I haven't got a convenient test install, and I've kind of lost track on the name mangling algorithms in Samba/VMS. It would help to know what the settings of DECC* are on the system in question, as Bernard noted. Richard Brodie PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
RE : Problem with VMS_SUPPORT.C
B. Z. Ledermman wrote: DISK$STORAGE:[SAMBA-2_2_7A-SRC.SOURCE.VMS]VMS_SUPPORT.C;262:(394) vms_statfs: $GETDVI ERROR for disk$lederman^:^[lederman^].: sts= 0144, iosb = 0144 The error is in what ever routine is converting UNIX filenames to VMS. It is setting the ":" as a filename character, and not as a device delimiter. And unless the SAMBA panic handler has been disabled, calling LIB$SIGNAL on fatal errors can really lead to some interesting and useless tracebacks. -John [EMAIL PROTECTED] Personal Opinion Only PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
RE : Problem with VMS_SUPPORT.C
[EMAIL PROTECTED] wrote: You are right that GETDVIW should be better than GETDVI, but this is clearly not the point. In addition, you CAN use a full file spec for $GETDVI, so it's not the point either. The addressing mode of the iosb is OK too. Correct. SYS$GETDVI/W ignores everything after the ":". Putting an & sign on an array is a common bug that I have to remove from source code that I am fixing. The compiler usually does the right thing. An & sign is needed to pass a structure by address. Recommended compile options are /STANDARD=PORTABLE/WARN=ENABLE=(LEVEL4, QUESTCODE). The UNIX SAMBA version will compile using these settings with only a few informational diagnostics. If the UNIX version does not compile, the UNIX maintainers usually will accept a gdiff formatted patch to repair their code. Do not use /STANDARD=VAXC because that mode will hide programming errors. Well, it is very true that SOMEONE is doing unnecessary work, but it's not SAMBA. Samba is just a server, and does what the client asks it to do. If Samba retrieves the nb of free blocks, the only reason is that the client asked for it. Sure, the client has no understandable reason to do so, but it did. I think that in the Windows World, there is enough wonder in just observing what is done. Trying to understand WHY it's done is far too much for me. As an example, when you just right-click "Properties" on a file on the XP Explorer, it sends to Samba more than 10 consecutive requests to open that file, and one of those open requests is in WRITE mode ! I have not looked at Windows XP, but the ealier versions of SAMBA opened files READ/WRITE becuase it was too hard to change their fcntl() locking from READ locks to READ/WRITE if the client changed their mind. These open/writes should not update the file modification dates. The only way I see around this is to track to see if the file was actually modified and then use the XQP function to restore the dates to what they were when the file was opened. The I/O wrapper routines in Frontport keep a context structure that could be modified to do this, as they need this structure to track fcntl locking. See also the description for DECC$EFS_FILE_TIMESTAMPS in the 7.3-1 C RTL manual. -John [EMAIL PROTECTED] Personal Opinion Only PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
RE : Problem with VMS_SUPPORT.C
The disk on which I am testing (DISK$STORAGE) is ODS-5. Bart. PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Problem with VMS_SUPPORT.C
This e-mail contains confidential information or information belonging to the Credit Lyonnais Group entity sending it and is intended solely for the addressees. Any views expressed in this message are those of the individual sender and its contents do not constitute a commitment by Credit Lyonnais unless confirmed by letter or fax. The unauthorised disclosure, use, dissemination or copying (either whole or partial) of this e-mail, or any information it contains, is prohibited. E-mails are susceptible to alteration and their integrity cannot be guaranteed. Internet communications are not secured and therefore Credit Lyonnais shall not be liable for this e-mail if modified or falsified. If you are not the intended recipient of this e-mail, please delete it immediately from your system and notify the sender of the wrong delivery and the mail deletion. Seems like it treats the whole beast like a file name: what are your DECC$EFS* settings ? -Message d'origine- De : B. Z. Lederman <[EMAIL PROTECTED]> À : [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date : jeudi, 27. mars 2003 15:31 Objet : RE : Problem with VMS_SUPPORT.C xphp-ledermanb (16.32.216.244) connect to service lederman as user lederman (uid=12582913, gid=192) (pid 816) [2003/03/27 07:43:54, 0] DISK$STORAGE:[SAMBA-2_2_7A-SRC.SOURCE.VMS]VMS_SUPPORT.C;262:(394) vms_statfs: $GETDVI ERROR for disk$lederman^:^[lederman^].: sts= 0144, iosb = 0144 ^ ^^ Seems like it treats the whole beast like a file name: what are your DECC$EFS* settings ? [2003/03/27 07:43:54, 0]DISK$STORAGE:[SAMBA-2_2_7A-SRC.SOURCE.SMBD]DFREE.C;2:(142) WARNING: dfree is broken on this system [2003/03/27 07:45:27, 1]DISK$STORAGE:[SAMBA-2_2_7A-SRC.SOURCE.SMBD]SERVICE.C;1:(675) xphp-ledermanb (16.32.216.244) closed connection to servicelederman Status 144 is %SYSTEM-F-IVDEVNAM, invalid device name By the way, LIB$SIGNAL would be a better choice to output the error messages, as it usually translates the error status, and it will exit on fatal errors but continue on warnings. 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
xphp-ledermanb (16.32.216.244) connect to service lederman as user lederman (uid=12582913, gid=192) (pid 816) [2003/03/27 07:43:54, 0] DISK$STORAGE:[SAMBA-2_2_7A-SRC.SOURCE.VMS]VMS_SUPPORT.C;262:(394) vms_statfs: $GETDVI ERROR for disk$lederman^:^[lederman^].: sts= 0144, iosb = 0144 [2003/03/27 07:43:54, 0]DISK$STORAGE:[SAMBA-2_2_7A-SRC.SOURCE.SMBD]DFREE.C;2:(142) WARNING: dfree is broken on this system [2003/03/27 07:45:27, 1]DISK$STORAGE:[SAMBA-2_2_7A-SRC.SOURCE.SMBD]SERVICE.C;1:(675) xphp-ledermanb (16.32.216.244) closed connection to servicelederman Status 144 is %SYSTEM-F-IVDEVNAM, invalid device name By the way, LIB$SIGNAL would be a better choice to output the error messages, as it usually translates the error status, and it will exit on fatal errors but continue on warnings. PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
RE : Problem with VMS_SUPPORT.C
Hi. Could you give me a copy of the full line (or lines) of the log where the error appears ? It should look like "$GETDVI ERROR for xxx: sts = nnn, iosb=yyy" You are right that GETDVIW should be better than GETDVI, but this is clearly not the point. In addition, you CAN use a full file spec for $GETDVI, so it's not the point either. The addressing mode of the iosb is OK too. Actually, there is probably something specific on your site that makes some bug appear, because this problem does not appear here or anywhere else as far as I know. Anyway, I need the full error message to work on it. > Why would you need to retrieve this information when reading files? It > seems to me that SAMBA is doing a lot of unnecessary work here. Well, it is very true that SOMEONE is doing unnecessary work, but it's not SAMBA. Samba is just a server, and does what the client asks it to do. If Samba retrieves the nb of free blocks, the only reason is that the client asked for it. Sure, the client has no understandable reason to do so, but it did. I think that in the Windows World, there is enough wonder in just observing what is done. Trying to understand WHY it's done is far too much for me. As an example, when you just right-click "Properties" on a file on the XP Explorer, it sends to Samba more than 10 consecutive requests to open that file, and one of those open requests is in WRITE mode ! 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
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
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
