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

Bug#1744: dpkg: cannot scan updates directory `/var/lib/dpkg/updates/': No such file or directory



Raul Miller: "Bug#1744: dpkg: cannot scan updates directory `/var/lib/dpkg/updates/': No such file or directory" (Oct 26, 18:24):
> There's a problem with the umsdos file system that prevents scandir(3)
> from working right -- it gives ENOENT instead of EOF upon successful
> termination.  This occurs because readdir returns ENOENT upon reaching
> the end of the directory.  The msdos file system has the same
> problem.  Here's a patch:
>
> --- linux-1.3.29/fs/msdos/dir.c.dist	Thu Oct 26 18:11:01 1995
> +++ linux-1.3.29/fs/msdos/dir.c	Thu Oct 26 18:12:34 1995
> @@ -86,7 +86,7 @@
>  			filp->f_pos = 0;
>  	}
>  	if (filp->f_pos & (sizeof(struct msdos_dir_entry)-1))
> -		return -ENOENT;
> +		return NULL;
>  	bh = NULL;
>  	while ((ino = msdos_get_entry(inode,&filp->f_pos,&bh,&de)) > -1) {
>  		if (!IS_FREE(de->name)

The above doesn't look like the right fix: -ENOENT may not be the right
value to return, but the above return value is meant to catch a bogus
file position pointer rather than catch the end of the file.  A better
error might be -EINVAL for that case (it means that somebody did a seek
with a bad value at some point).

> --- linux-1.3.29/fs/umsdos/dir.c.dist	Thu Oct 26 18:11:02 1995
> +++ linux-1.3.29/fs/umsdos/dir.c	Thu Oct 26 18:13:51 1995
> @@ -259,7 +259,7 @@
>  }
>  /*
>  	Read count directory entries from directory filp
> -	Return a negative value from linux/errno.h.
> +	Return a NULL to indicate end of file
>  	Return > 0 if success (the amount of byte written to dirent)
>  */
>  static int UMSDOS_readdir(
> @@ -284,7 +284,7 @@
>  	}
>  	PRINTK (("UMSDOS_readdir out %d count %d pos %Ld\n",ret,count
>  		,filp->f_pos));
> -	return count == 0 ? -ENOENT : ret;
> +	return count == 0 ? NULL : ret;
>  }
>  /*
>  	Complete the inode content with info from the EMD file

How about

	return count ? : ret;

instead? At the very least a NULL is definitely wrong, as we're
returning an integer, not a pointer.

		Linus


Reply to: