open returning EINVAL; minor fs patch

[Nickolai Zeldovich]

After updating to the latest CVS version of arla (as of ~Mar 23rd)
I've been seeing some problems with pine/pico's temporary files..
Pico creates a temporary file like ~/#pico91412#, and periodically
dumps the current buffer there.  On occasion, it somehow gets arla
into a state where any attempt to open the file returns EINVAL, but
stat'ing the file works fine, and unlink also works.  I'm not sure
what special things pico might be doing to cause this, though..

Is there any debugging information that might be useful in tracking
down this bug?  Attached is the output of xfsdebug (almost-all),
corresponding to running "cat ~/#picoNNNNN#" in this state.

Also, attached is a patch to "fs" that allows one to reduce the
debugging level.  It would appear that, right now, once you go up
to almost-all debugging, you can never reduce the verbosity of xfs.

-- kolya

fs patch:

Index: fs.c
===================================================================
RCS file: /stacken-cvs/arla/appl/fs/fs.c,v
retrieving revision 1.95
diff -u -r1.95 fs.c
--- fs.c	2001/01/25 15:27:05	1.95
+++ fs.c	2001/03/27 07:46:29
@@ -1359,7 +1359,7 @@
 	
 	textflags = argv[1];
     
-	ret = parse_flags (textflags, xfsdebug_units, flags);
+	ret = parse_flags (textflags, xfsdebug_units, 0);
 	
 	if (ret < 0) {
 	    fprintf (stderr, "xfsdebug: unknown/bad flags `%s'\n",

xfsdebug output:

Mar 27 02:20:52 orbit /kernel: xfs_lock: cfbf3180, flags 0x1030002
Mar 27 02:20:52 orbit /kernel: xfs_lock before: lk flags: 16777216 share: 0 wait: 0 excl: 0 holder: -1
Mar 27 02:20:52 orbit /kernel: xfs_lock: lk flags: 16778240 share: 0 wait: 0 excl: 1 holder: 90761
Mar 27 02:20:52 orbit /kernel: xfs_access mode = 0100
Mar 27 02:20:52 orbit /kernel: xfs_access(0100) = 0
Mar 27 02:20:52 orbit /kernel: xfs_lock: cfc4d540, flags 0x1010002
Mar 27 02:20:52 orbit /kernel: xfs_lock before: lk flags: 16777216 share: 0 wait: 0 excl: 0 holder: -1
Mar 27 02:20:52 orbit /kernel: xfs_lock: lk flags: 16778240 share: 0 wait: 0 excl: 1 holder: 90761
Mar 27 02:20:52 orbit /kernel: xfs_unlock: cfbf3180, flags 0x0, l c3ebdfb0, ap cf923d28
Mar 27 02:20:52 orbit /kernel: xfs_unlock: lk flags: 16778240 share: 0 wait: 0 excl: 1 holder: 90761
Mar 27 02:20:52 orbit /kernel: xfs_unlock: return 0
Mar 27 02:20:52 orbit /kernel: xfs_access mode = 0400
Mar 27 02:20:52 orbit /kernel: xfs_access(0400) = 0
Mar 27 02:20:52 orbit /kernel: xfs_open
Mar 27 02:20:52 orbit /kernel: xfs_open_valid
Mar 27 02:20:52 orbit /kernel: xfs_message_rpc opcode = 12
Mar 27 02:20:52 orbit /kernel: xfs_alloc: xfs_allocs - xfs_frees 490
Mar 27 02:20:52 orbit /kernel: xfs_alloc: xfs_allocs - xfs_frees 491
Mar 27 02:20:52 orbit /kernel: xfs_alloc: xfs_allocs - xfs_frees 492
Mar 27 02:20:52 orbit /kernel: xfs_message_receive opcode = 1
Mar 27 02:20:52 orbit /kernel: xfs_message_wakeup error: 22
Mar 27 02:20:52 orbit /kernel: xfs_message_rpc this_process->error_or_size = 0
Mar 27 02:20:52 orbit /kernel: xfs_message_rpc opcode ((xfs_message_wakeup*)(this_process->message))->error = 22
Mar 27 02:20:52 orbit /kernel: xfs_open_valid: error = 22 
Mar 27 02:20:52 orbit /kernel: xfs_inactive, cfc4d540
Mar 27 02:20:52 orbit /kernel: xfs_fsync: cfc4d540 
Mar 27 02:20:52 orbit /kernel: xfs_unlock: cfc4d540, flags 0x0, l c37e75b0, ap cf923d7c
Mar 27 02:20:52 orbit /kernel: xfs_unlock: lk flags: 16778240 share: 0 wait: 0 excl: 1 holder: 90761
Mar 27 02:20:52 orbit /kernel: xfs_unlock: return 0       
Mar 27 02:20:52 orbit /kernel: return: xfs_inactive