[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

libc6 v2.0.7 link/unlink & rename problems



Hi,

   I running into some headaches with the libc6 libraries and wonder if you
could give me a few pointers. I have a Dell Optiplex 333mhz with 2940u/uW
scsi and a pentium.

    1) I have DosLInux precompiled binary for Linux v2.2.1 with UMSDOS
       dentry-pre 0.84 ( level  0.4) with the the old libc6-dev_2.0.7t-1.deb
       precompiled binaries and the egcs v1.0.3 precompiled binaries with
       make v3.77.

      I've also replaced the libc6 from your site with 
      libc6-dev_2.0.7.19981211-6.deb precompiled binaries thinking this is
      the latest and greatest before having to go to glibc v2.1


      In either case above it has not solved the problem I'm having.

      The util-linux-2.9i contains the passwd routine from the admutil v1.24.
       Upon compiling and trying to run it, the setpwnam.c function has
       a problem whereby the /etc/passwd file gets erased due to it being
       out of sync. The problem is due to the link(), unlink() and rename()
       function calls in the libc6. I've taken the basic call processing
       out and put it into a test program that specifically does link,unlink
       and rename. If I single step via  a pause after each function call
       the link & unlink seem to work ok although the link that is dropped
       is never totally released but doesn't seem to cause any problems for
       root -but for everyone else it does. So the inode count can be
       seen to increase from one to two to one. But if the program is
       rapidly single stepped, then the inode count is stuck at two and
       doesn't go back to one.

       Morever, when doing a rename (i.e  from new passwd file to the new
       one using a rename, a sync error occurs whereby erasing the old
       original one, which upon the rename function generates errno=2
       as file/directory doesn't exist which then errors out the routine.
       Thus rename is working properly.


  B). I've tried this exact same routine on a Doslinux v2.0.36 distribution
      running libc5.4.46 with a UMSDOS beta 0.6 (level 0.4) having the same
      gcc compiler of egcs v1.0.3 and it works correctly.

  Conclusion:     1) have a inode link that is two or one depending on the
                     speed of executing the program and is never totally erased
                  2). The rename() function drops the link prematurely causing
                      a errno=2


---------------   Here is my program that immitates the passwd routine -----
Note:    Need to put dummy data in /root/link/patmp before starting

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <errno.h>

#define PTMP "/root/link/ptmp"
#define PTMPTMP "/root/link/ptmptmp"
#define PATMP "/root/link/patmp"
#define PATMPOLD "/root/link/paold"

main() {

int mnum;
int ftmptmp;
int lnkerr;
int wrterr;
extern int errno;

    umask(0);
    ftmptmp=open(PTMPTMP, O_CREAT | O_EXCL | O_RDWR, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
     if ( ftmptmp == -1) {
            printf(" file open errno=%d\n",errno);
            close(ftmptmp);
            exit(1);
       }

printf(" ptmptmp opened\n");
mnum=getchar();

lnkerr=link(PTMPTMP, PTMP);
  if(lnkerr == -1) {
        printf(" failed to link\n");
     }

printf(" ptmptmp linked to ptmp\n");
mnum=getchar();

lnkerr=unlink(PTMPTMP);
     if(lnkerr == -1) {
            printf(" failed to unlink\n");
           }


printf(" unlink ptmptmp\n");
mnum=getchar();

wrterr=write(ftmptmp, "Mikes new data\n", 15); 
      if( wrterr == -1) {
            printf(" write erro =%d\n",errno);
          }

printf(" wrote new data to ptmp\n");
mnum=getchar();

lnkerr=link(PATMP, PATMPOLD);
     if(lnkerr == -1) {
            printf(" failed to link\n");
       }

printf(" link previous file copy to make a backup called old\n");
mnum=getchar();

lnkerr=rename(PTMP,PATMP);
 if(lnkerr == -1) {
      printf(" DAM it didn't work either errno=%d\n",errno);
     } 
close(ftmptmp);
}




Reply to: