More error message changes? (Re: mkdir diff)
There were a few other places where I noticed (long time ago, but I've now written it all down) somewhat strange messages: mkdir / gives: mkdir: /: Is a directory whereas mkdir /usr gives: mkdir: /usr: File exists Is this a bug in the kernel to return EISDIR in case of "/" or is it a 'feature'? Further, various other programs have a variant of the message weirdness that mkdir had, though this is defensible in some cases as another message is added, e.g. in sh: echo "aa" /tmp/a/b gives: cannot create /tmp/a/b: directory nonexistent. The other cases are present in rm, touch, chmod, cat, ls, cp, mv (possible more...). The messages are all ok if one remembers the exact meaning of the error message as decribed in intro(2) but the short messages that strerror et al produce are misleading when one does not expand further (as opposed to e.g. the sh example) For the following I assume /tmp/e is a file, and /tmp/a does not exist. rm /tmp/e/f gives: rm: /tmp/e/f: Not a directory (better: rm: /tmp/e: Not a directory) touch /tmp/a/b: touch: /tmp/a/b: No such file or directory (better: touch: /tmp/a: No such file or directory, as touch is supposed to create the file if it doesn't exist) touch /tmp/e/f: touch: /tmp/e/f: Not a directory (better: touch: /tmp/e: Not a directory) chmod +x /tmp/e/f: chmod: /tmp/e/f: Not a directory (better: chmod: /tmp/e: Not a directory) cat /tmp/e/f: cat: /tmp/e/f: Not a directory (better: cat: /tmp/e: Not a directory) ls /tmp/e/f: ls: /tmp/e/f: Not a directory (better: ls: /tmp/e: Not a directory) cp /tmp/e/f f: cp: /tmp/e/f: Not a directory (better: cp: /tmp/e: Not a directory) mv /tmp/e/f f mv: rename /tmp/e/f to f: Not a directory if g does not exist: mv /tmp/e/f g/f mv: rename /tmp/e/f to g/f: Not a directory (not sure what do to here, 2 directories, so check/mention both with an expanded message?) Of course, these messages can changed by changing: 1. the messages that go with errno, e.g. "Not a directory" to "Part of the directory name is not a directory" or something 2. check for these cases in the given programs. 3. expand the error message as sh does. I actually like the idea of making the messages that strerror produces more verbose but maybe everyone feels the current messages should stay as they are standard?. Regards, Wouter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pppd mkdir diff
Alfred Perlstein wrote:
[ mkdir ]
I'll commit the patch shortly.
Here's a better patch, it checks for multiple slashes, so mkdir
/tmp/aa///bb will give:
mkdir: /tmp/aa: No such file or directory
Also, renamed the function to dirname as it does the same as dirname(1).
Regards,
Wouter
diff -ruN /usr/src/bin/mkdir.orig/mkdir.c /usr/src/bin/mkdir/mkdir.c
--- /usr/src/bin/mkdir.orig/mkdir.c Sat Sep 4 05:19:38 1999
+++ /usr/src/bin/mkdir/mkdir.c Sat Jan 13 10:45:07 2001
@@ -58,6 +58,8 @@
intbuild __P((char *, mode_t));
void usage __P((void));
+char *dirname __P((char *));
+
int vflag;
@@ -108,7 +110,10 @@
if (build(*argv, omode))
success = 0;
} else if (mkdir(*argv, omode) 0) {
- warn("%s", *argv);
+ if (errno == ENOTDIR || errno == ENOENT)
+ warn("%s", dirname(*argv));
+ else
+ warn("%s", *argv);
success = 0;
} else if (vflag)
(void)printf("%s\n", *argv);
@@ -129,6 +134,22 @@
}
exit(exitval);
}
+
+
+char *dirname(char *path) {
+ char *slash;
+
+ while (path[ strlen(path)-1 ] == '/') path[ strlen(path)-1 ] = 0;
+
+ slash = strrchr(path, '/');
+ if (slash) {
+ *slash = 0;
+ while (path[ strlen(path)-1 ] == '/') path[ strlen(path)-1 ] = 0;
+ }
+
+ return path;
+}
+
int
build(path, omode)
Re: pppd mkdir diff
Alfred Perlstein wrote: 1. a pppd patch which sends the pppd messages to stderr. not sure about this one, I would open a PR about it. I'm not sure either :) Maybe everyone else uses gui frontend which reads pppd's syslog messages or starts pppd as root? Ok, I may be misreading this, but this doesn't fix it really: mkdir /tmp/a/b/c/d/e/f/s perhaps if you called "stat" in a loop to on each patch component until it failed you'd be able to trim off the directory paths one by one. I don't think it's useful for mkdir to check which exact part of the path of the parent directory does exist. The fix just makes mkdir say the parent directory doesn't exist (instead of the previously wierd "the dir you wanted me to create doesn't exist" type of error message :). Regards, Wouter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
pppd mkdir diff
L.S.
Here are two patches I've been using for a while on both 3.3R and 4.1R:
1. a pppd patch which sends the pppd messages to stderr.
This is useful for dialup connections under X (I use a script to startup
pppd, when the script is killed, so is pppd). Now the pppd startup
messages are sent to e.g. the xterm the script is started on (using
syslog.conf I can get this too but then all xterms get the messages
which is annoying; or is there a way to do this that I'm not aware of?).
Perhaps it's useful as a compile option or a runtime option.
2. a mkdir patch changing an error message.
If for example /tmp/aa does not exist then mkdir /tmp/aa/bb will report
/tmp/aa/bb: No such file or directory
This is true but not the point. The patch makes it say:
/tmp/aa: No such file or directory
Wouter
--- /usr/src/usr.sbin/pppd/main.c~ Sun Aug 29 17:47:05 1999
+++ /usr/src/usr.sbin/pppd/main.c Mon Jun 12 21:09:47 2000
@@ -191,7 +191,7 @@
#ifdef ULTRIX
openlog("pppd", LOG_PID);
#else
-openlog("pppd", LOG_PID | LOG_NDELAY, LOG_PPP);
+openlog("pppd", LOG_PID | LOG_NDELAY | LOG_PERROR, LOG_PPP);
setlogmask(LOG_UPTO(LOG_INFO));
#endif
diff -ruN mkdir.orig/mkdir.c mkdir/mkdir.c
--- mkdir.orig/mkdir.c Sat Sep 4 05:19:38 1999
+++ mkdir/mkdir.c Fri Jan 5 07:56:35 2001
@@ -58,6 +58,8 @@
intbuild __P((char *, mode_t));
void usage __P((void));
+char *path_prefix __P((char *));
+
int vflag;
@@ -108,7 +110,10 @@
if (build(*argv, omode))
success = 0;
} else if (mkdir(*argv, omode) 0) {
- warn("%s", *argv);
+ if (errno == ENOTDIR || errno == ENOENT)
+ warn("%s", path_prefix(*argv));
+ else
+ warn("%s", *argv);
success = 0;
} else if (vflag)
(void)printf("%s\n", *argv);
@@ -129,6 +134,19 @@
}
exit(exitval);
}
+
+
+char *path_prefix(char *path) {
+ char *slash;
+
+ if (path[ strlen(path)-1 ] == '/') path[ strlen(path)-1 ] = 0;
+
+ slash = strrchr(path, '/');
+ if (slash) *slash = 0;
+
+ return path;
+}
+
int
build(path, omode)
Re: uncool MO disk problems
L.S. Update on previous mail a while back. I tried the latest sym driver from the CVS tree (into fbsd 3.3) but little has changed (haven't checked what happens with 640MB 2048 b/s disks yet): 4. Formatting ufs on fbsd: newfs hangs (unkillable). This now works. 3. ufs disk formatted on obsd: I cannot use da0a but mounting da0 (with -t ufs) works. After I change the disklabel's '16 partitions:' to '8 partitions:' I can mount da0a (and read/write) but unmounting fails (umount - unkillable process). No change (also goes for a disk formatted under fbsd). Here's what happens after I mount the disk, and have written something to it, then try to unmount: --- ps axl for the umount process shows: cdwait D+ When I now halt the machine: after a short while: syncing disks... done then after about 3 minutes I get into DDB: page fault while in kernel mode snip kernel: type 12 trap, code=0 stopped at ffs_sync+0x1f movl 0xc(%esi),%esi a vm/vfs problem? Second situation: mounting a write protected disk (RW, but the OS should change that itself to a read only mount if the disk is write protected, which it does recognize at mount time). unmounting failed, at reboot the machine tried it some more, gave up said: giving up: rebooting which it did; unfortunately, it didn't unmount the file systems which could be unmounted so started checking the ffs partitions next time I booted fbsd. As apart from Gerard's response there were no reactions of anyone with similar problems nor of people using MO drives without problems, can I assume everyone using MO drives nuked fbsd and uses something else now? Or does anyone use MO drives with 4.0 or 4.1 without the problems I mentioned (in this and my previous mail) ? Btw, I compiled the kernel with DDB now so if there's any use for it I can give the trace information etc. Wouter PS. CC responses to my mail address please. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
uncool MO disk problems
L.S. (the following is on fbsd 3.3 R) I tried use 2048 bytes/sector MO media recently, but it doesn't work. Disklabel complains about /boot/boot2 being to large or something. It seems to have worked (more or less) up until 3.1 as I saw a few posts in the SCSI list, e.g. From: "Kenneth D. Merry" [EMAIL PROTECTED] Date: Thu, 25 Feb 1999 15:54:01 -0700 (MST) replying to Arnaud Kopp who was using it in fbsd 3.1. (not without problems, but at least disklabel/newfs worked). So, what happened after 3.1? Trying to mount an already formatted 640MB msdos format disk gives the following errors and the mount does not succeed: (da0:sym0:0:3:0): READ(10). CDB: 28 0 70 6f 20 6c 0 0 1 0 (da0:sym0:0:3:0): ILLEGAL REQUEST asc:21,0 (da0:sym0:0:3:0): Logical block address out of range (da0:sym0:0:3:0): READ(10). CDB: 28 0 4f 49 0 1 0 0 1 0 (da0:sym0:0:3:0): ILLEGAL REQUEST asc:21,0 (da0:sym0:0:3:0): Logical block address out of range (da0:sym0:0:3:0): READ(10). CDB: 28 0 20 20 53 50 0 0 1 0 (da0:sym0:0:3:0): ILLEGAL REQUEST asc:21,0 (da0:sym0:0:3:0): Logical block address out of range (da0:sym0:0:3:0): READ(10). CDB: 28 0 e9 e 2 7f 0 0 1 0 (da0:sym0:0:3:0): ILLEGAL REQUEST asc:21,0 (da0:sym0:0:3:0): Logical block address out of range (da0:sym0:0:3:0): READ(10). CDB: 28 0 70 6f 20 6c 0 0 1 0 (da0:sym0:0:3:0): ILLEGAL REQUEST asc:21,0 (da0:sym0:0:3:0): Logical block address out of range (da0:sym0:0:3:0): READ(10). CDB: 28 0 4f 49 0 1 0 0 1 0 (da0:sym0:0:3:0): ILLEGAL REQUEST asc:21,0 (da0:sym0:0:3:0): Logical block address out of range (da0:sym0:0:3:0): READ(10). CDB: 28 0 20 20 53 50 0 0 1 0 (da0:sym0:0:3:0): ILLEGAL REQUEST asc:21,0 (da0:sym0:0:3:0): Logical block address out of range (da0:sym0:0:3:0): READ(10). CDB: 28 0 e9 e 2 7f 0 0 1 0 (da0:sym0:0:3:0): ILLEGAL REQUEST asc:21,0 (da0:sym0:0:3:0): Logical block address out of range dscheck: b_bcount 512 is not on a sector boundary (ssize 2048) FYI, when mounting a dos formmatted 230 MB disk I also get 'Logical block address out of range' errors/warnings but the mount succeeds. [btw, why are the od devices still in /dev if they are not to be used? ] This is not all though. With 512 b/s media there are also problems. 1. ext2fs formatted disks: trying to unmount a write protected disk locks up the machine (i.e. I can't do anything under X, machine is not on a network so can't telnet in, nor read console messages if the kernel is in a loop somewhere, and no, I don't feel like trying it on the console at the moment, I tried a few other things and have been rebooting way to much.) A side note: The ext2fs code in FreeBSD is very unstable: 1a) doing a rm -Rf in a large tree has given me regular panic-halt-reboot 's 1b) files in directories with lots of files (like 900-1000) will cause some files to mysteriously disappear (still in the directory listing, but trying to access the file will fail, I rescued the files by copying the entire tree, adding more files to the directory of the ext2 fs, other files were now inaccessible.., so I could copy the missing ones too..) From a few posts on usenet I gather the much better Open/Net BSD ext2 code won't be imported as noone cares enough. Well, in that case please label the ext2 code in the config file as dangerous (maybe even a message when mounting an ext2fs fs). 2. msdos formatted MO disks. Mounting /unmounting a write protected disk works unless I (yes, just had to try to see what would happen) you write a file to the write protected disk. There's a message saying the disk is write protected and nothing bad happens at that time, but when trying the unmount the device, the OS tries to write the data to disk anyway, fails, (lots of 5's on screen), panic-reboot. 3. ufs disk formatted on obsd: I cannot use da0a but mounting da0 (with -t ufs) works. After I change the disklabel's '16 partitions:' to '8 partitions:' I can mount da0a (and read/write) but unmounting fails (umount - unkillable process). 4. Formatting ufs on fbsd: newfs hangs (unkillable). Any ideas on what to change ? patches ? (please CC me as I'm not currently on this list). Wouter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
uncool MO disk problems, addendum
L.s. small addendum: - it's fbsd 3.3R on i386 as you may have guesssed from the mail headers. - I use the new fbsd symbios/ncr scsi driver (the README says latest revision is sym-0.12.0-19991127). Also my mail address is [EMAIL PROTECTED], reply on the previous mail will give spaces in the mail address.. Wouter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: dutch keyboard map (+sort note)
Christian Weisgerber wrote: Ollivier Robert [EMAIL PROTECTED] wrote: As there isnt a dutch keymap for syscons, ^ That's an acute accent (the same diacritic as in ''), not an apostrophe. In 8859-1 yes but not in 8859-15 (aka Latin9)... Well, the original message was in Latin 1. You re-interpretating it as Latin 9 is not fair. What are you both reading from a typo? I use 2 keyboards, US NL and acute on the one has apostrophe on the other in the exact same position. Guess what happens sometimes :) Btw, I don't see why I had to load the screenmap myself (unless I reboot of course). Why doesn't sysinstall do this when I tell it to use iso8859-ibm mapping? Wouter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
dutch keyboard map (+sort note)
L.S. As there isn´t a dutch keymap for syscons, I made one (iso8859-1) but I´m having some problems. First, how do I enable/use dead keys? (which look like they´re being defined in the standard map, a dump of the defaults gives e.g. this line dced 184 ( 'c' 231 ) ( 'C' 199 ) ) Secondly, the console screenmapping (iso88559-1- ibm) doesn´t seem to work properly (I´ve set it with /stand/sysinstall) E.g. if I enter the code 171 (« (guillemotleft)) then I actually see ½ (one half) which has code 189. What´s going on? On a unrelated note, for those interested in my separate alpha/numeric sort function, there was an obvious error in the version I sent to the list a while back. A new (better) version which is much closer to lexicographical sorting is available from my www page below (the patch also uses option N to enable it now). Regards, Wouter PS. All this is on fbsd 3.3-RELEASE. - http://www.xs4all.nl/~whs To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ls: alpha - numeric sorting
L.S. Here are patches for FreeBSD's ls (from version 3.3 release) and OpenBSD's ls (version 2.6, didn't actually test this obsd patch as I'm working on a FreeBSD machine at the moment). What it does is add an option (yes another one) to sort alpha numeric separately, i.e. instead of something like gsi-0.9.3p1.tgz gsi-0.9.3p10.tgz gsi-0.9.3p11.tgz gsi-0.9.3p12.tgz gsi-0.9.3p13.tgz gsi-0.9.3p14.tgz gsi-0.9.3p15.tgz gsi-0.9.3p16.tgz gsi-0.9.3p17.tgz gsi-0.9.3p18.tgz gsi-0.9.3p2.tgz gsi-0.9.3p3.tgz gsi-0.9.3p4.tgz gsi-0.9.3p5.tgz gsi-0.9.3p6.tgz gsi-0.9.3p7.tgz gsi-0.9.3p8.tgz gsi-0.9.3p9.tgz you will get: gsi-0.9.3p1.tgz gsi-0.9.3p2.tgz gsi-0.9.3p3.tgz gsi-0.9.3p4.tgz gsi-0.9.3p5.tgz gsi-0.9.3p6.tgz gsi-0.9.3p7.tgz gsi-0.9.3p8.tgz gsi-0.9.3p9.tgz gsi-0.9.3p10.tgz gsi-0.9.3p11.tgz gsi-0.9.3p12.tgz gsi-0.9.3p13.tgz gsi-0.9.3p14.tgz gsi-0.9.3p15.tgz gsi-0.9.3p16.tgz gsi-0.9.3p17.tgz gsi-0.9.3p18.tgz Much better! This would be great on ftp servers (trying to find the latest tgz for a given package in a list of around 50 or more is a nuisance with lexicographical ordering). The sort option is invoked with -n on fbsd, -N on obsd (change as you like...). I've also attached a complete little test program with debug output etc. The code could be improved by renaming some variables to longer names (couldn't think of any good ones ;) and probably the implementation too (haven't tried to optimize). Enjoy, Wouter alpha_num_cmp.c.gz whs_fbsd_ls.diff.gz whs_obsd_ls.diff.gz
Re: ncr scsi timeout
Kenneth D. Merry wrote: In general, the stock NCR driver isn't being actively maintained, and your problem could be the result of a bug in the driver, or some problem with your MO drive. It's hard to say for sure. Gerard's driver is actively maintained, though, so if you still have problems with his driver, it'll be easier to get the problems fixed. I'm using a Tekram DC 390U (ncr 875 ultra, not wide) controller which the readme said was supported, so I just compiled a new kernel with the new driver and everything works hunky dory now :-) Thanks. Wouter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
