on 17/02/2008 13:39 Andriy Gapon said the following: > Should newfs_msdos be able to work on "whole" cdX/acdX device ? > [ufs/ffs] newfs can do it. > But with newfs_msdos I had to run disklabel first and then I could > create a filesystem on cdXa, but I couldn't do it on the whole disk. It seems that the reason for this newfs_msdos behavior is in the following lines: if (ioctl(fd, DIOCGSECTORSIZE, &dlp.d_secsize) == -1) errx(1, "Cannot get sector size, %s", strerror(errno)); if (ioctl(fd, DIOCGFWSECTORS, &dlp.d_nsectors) == -1) errx(1, "Cannot get number of sectors, %s", strerror(errno)); if (ioctl(fd, DIOCGFWHEADS, &dlp.d_ntracks)== -1) errx(1, "Cannot get number of heads, %s", strerror(errno)); While a failure to get sector size is a serious situation indeed, number of sectors per track and number of heads are just relics of the past and are not applicable to all types of should-be-supported media. What's even more funny is that those values can be set via command line options and in that case values from ioctl are not used at all. Because those numbers are used by msdosfs on-disk structures we have to provide some reasonable values for them even if they are meaningless with respect to physical media organization. An example of simple calculations can be found in bsdlabel.c. I see two approaches: 1) fake those properties in device drivers, primarily cd(4) and acd(4); benefit: this can help other utilities besides newfs_msdos 2) fake those properties in newfs_msdof; benefit: this would help with other physical devices that can host FAT; Or maybe do both. -- Andriy GaponReceived on Thu Feb 21 2008 - 11:32:08 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:27 UTC