Article 126292 of comp.os.vms: Path: nntpd.lkg.dec.com!btgmax.zko.dec.com!cowan From: cowan@btgmax.zko.dec.com (Ken Cowan) Newsgroups: comp.os.vms Subject: Re: DECCRTL function mkdir produces placed directories (was Why is MAIL.MAI a placed file ?) Date: 3 Aug 1995 20:46:19 GMT Organization: Digital Equipment Corporation Lines: 109 Distribution: world Message-ID: <3vrcir$jdf@nntpd.lkg.dec.com> References: <3v3arc$no6@rs18.hrz.th-darmstadt.de> <3v57fp$mib@rs18.hrz.th-darmstadt.de> <1995Jul27.095321.2099@yrsk.demon.co.uk> <3vo50l$igo@rs18.hrz.th-darmstadt.de> Reply-To: cowan@rtl.enet.dec.com NNTP-Posting-Host: btgmax.zko.dec.com X-Newsreader: mxrn 6.18-9 In article , dpm@access5.digex.net (David P. Murphy) writes: |>mueller@axp612.gsi.de (W.F.J.Mueller) writes: |> |>>Thanks to Hein for pointing out the reason of placed MAIL.MAI files. |>>In my original posting I also mentioned that directories get placed under |>>certain circumstances. This turns out to be a `feature' of the DEC C RTL |>>function mkdir(). Try: |>> #include |>> main () { mkdir("test",0); } |>>and dump/head test.dir. One gets |>>Map area |>> Retrieval pointers |>> Placement control: Exact |>> Count: 7 LBN: 1854678 |>>so mkdir() produces a directory with placement control. There isn't much |>>sense in this, so I'd call this `feature' a bug. |> |>oh yeah, it's a bug. |> |>this is from the [V61.CRTL.LIS]F_MISC.LIS listing, slightly formatted |>to fit in an eighty-character display: |> |>18556 /* |>18557 * MKDIR |>18558 * |>18559 * Make a directory. |>18560 * |>18561 * Inputs: dir_spec - VMS or DEC/Shell directory specification |>18562 * mode - file protection |>18563 * uic - user identification code identifying owner of |>18564 * created directory (optional) |>18565 * max_versions - max number of file versions to be retained in |>18566 * created directory (optional) |>18567 * r_v_number - volume to place created directory if the device |>18568 * is part of the volume set (optional) |>[...] |>18573 */ |>18574 int decc$mkdir(va_alist) |>18575 va_dcl |>[...] |>18587 1 unsigned short max_versions = 0, r_v_number = 0; |>[...] |>18617 4 r_v_number = va_arg(ap, unsigned short); |>[...] |>18676 1 ret_val = lib$create_dir(&devdir_spec, uic_ptr, |>18677 1 &fcb->xabpro->xab$w_pro, &fcb->xabpro->xab$w_pro, |>18678 1 max_versions_ptr, &r_v_number); |> |>and for those who are not intimately familiar with the LIB$() call, |>here's the significant portion of the [V61.LIBRTL.LIS]LIBCREDIR.LIS listing: |> |>; 0744 3 !+ |>; 0745 3 ! Establish the placement of the created directories. |>; 0746 3 ! Note that if placement is specified, it is required. |>; 0747 3 !- |>; 0748 3 |>; 0749 3 IF NOT NULLPARAMETER(6) |>; 0750 3 THEN |>; 0751 4 BEGIN |>; 0752 4 FIB[FIB$V_EXACT] = 1; ! Exact placement |>; 0753 4 FIB[FIB$B_ALALIGN] = FIB$C_LBN; ! RVN and LBN placement |>; 0754 4 FIB[FIB$W_LOC_RVN] = .(.RVN)<0,16>; ! Required RVN |>; 0755 3 END; |> |>obviously there's a big difference between "passing NULL" and |>"passing the address of an int containing zero"! the mkdir() call to |>LIB$CREATE_DIR() will _always_ request a specific relative-volume-number, |>but it shouldn't unless the application's invocation of mkdir() includes |>that optional argument. |> |>the funny part is that the original code for mkdir() had the exact same |>problem with a _different_ optional argument, as can be seen in this comment |>from the F_MISC listing: |> |> 108 * 015 Bill Robinson 24-Mar-1993 |> 109 * Fix QAR 140: mkdir() uic was defaulting to addresss of 0 |> 110 * (uic of parent directory), rather than a value of 0 (uic |> 111 * of the creating process, or uic of parent directory if |> 112 * process is privileged). |> |>it's too bad that mr. robinson corrected the treatment of just that argument |>without noticing that _rvn_ was in a similar bind. |> |>i also notice that one "Ken Cowan" edited this file no fewer than six times |>during the summer of 1993. was this fixed in V6.2 or shall i submit an SPR? |> |>ok |>dpm |>-- |>David P. Murphy, systems programmer |>mailto:dpm@access.digex.net COGITO |>ftp://ftp.digex.net/pub/access/dpm ERGO |>http://www.access.digex.net/~dpm DISCLAIMUM |> Is this my 15 seconds of fame? :-) The bug is still present in our current sources. This is the first report I've seen of it. Thanks for also telling us what the fix is! I'll put the bug on the list. You don't need to submit an SPR. -- Ken Cowan, ZK2-3/Q8 cowan@rtl.enet.dec.com Digital Equipment Corporation decwrl!rtl!cowan 110 Spit Brook Rd, Nashua, NH 03062