From jin@adsl-63-198-35-122.dsl.snfc21.pacbell.net  Tue Feb 18 11:27:30 2003
Return-Path: <jin@adsl-63-198-35-122.dsl.snfc21.pacbell.net>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 98D2937B401
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 18 Feb 2003 11:27:30 -0800 (PST)
Received: from adsl-63-198-35-122.dsl.snfc21.pacbell.net (adsl-63-198-35-122.dsl.snfc21.pacbell.net [63.198.35.122])
	by mx1.FreeBSD.org (Postfix) with ESMTP id C0AF043FB1
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 18 Feb 2003 11:27:28 -0800 (PST)
	(envelope-from jin@adsl-63-198-35-122.dsl.snfc21.pacbell.net)
Received: from adsl-63-198-35-122.dsl.snfc21.pacbell.net (localhost.pacbell.net [127.0.0.1])
	by adsl-63-198-35-122.dsl.snfc21.pacbell.net (8.12.6/8.12.6) with ESMTP id h1IJSHE2000772
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 18 Feb 2003 11:28:18 -0800 (PST)
	(envelope-from jin@adsl-63-198-35-122.dsl.snfc21.pacbell.net)
Received: (from jin@localhost)
	by adsl-63-198-35-122.dsl.snfc21.pacbell.net (8.12.6/8.12.6/Submit) id h1IJSFd4000771;
	Tue, 18 Feb 2003 11:28:15 -0800 (PST)
Message-Id: <200302181928.h1IJSFd4000771@adsl-63-198-35-122.dsl.snfc21.pacbell.net>
Date: Tue, 18 Feb 2003 11:28:15 -0800 (PST)
From: "Jin Guojun[DSD]" <jin@adsl-63-198-35-122.dsl.snfc21.pacbell.net>
Reply-To: j_guojun@lbl.gov
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: wierd file system behavior
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         48435
>Category:       kern
>Synopsis:       wierd file system behavior
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Feb 18 11:30:19 PST 2003
>Closed-Date:    Fri Oct 10 22:16:25 PDT 2003
>Last-Modified:  Fri Oct 10 22:16:25 PDT 2003
>Originator:     Jin Guojun[DSD]
>Release:        FreeBSD 4.7-RELEASE i386
>Organization:
>Environment:
System: FreeBSD adsl-63-198-35-122.dsl.snfc21.pacbell.net 4.7-RELEASE FreeBSD 4.7-RELEASE #1: Sat Oct 26 14:27:08 PDT 2002 jin@adsl.dsl.snfc21.pacbell.net:/usr/src/sys/compile/MinMax i386


	FreeBSD 4.7-RELEASE and 5.0-RELEASE

>Description:
	rm $dir/* then "tar -xf tar-file"
	can remove old directory ($dir) and create a new directory ($dir).
	< in this example, $dir/ == test/ >

	I have not seen this behavior on 4.6.2 or earlier versions and
	any other Unix file systems.

>How-To-Repeat:

[37] FreeBSD-4.7: mkdir test
[38] FreeBSD-4.7: ll -i test
total 4
19232 drwxr-xr-x  2 jin   wheel   512 Feb 18 11:12 ./
18964 drwxrwxrwt  6 root  wheel  1024 Feb 18 11:12 ../
[39] FreeBSD-4.7: tar -xvf x
test/
test/tp2u
[40] FreeBSD-4.7: !l
ll -i test
total 6
19232 drwxr-xr-x  2 jin   wheel   512 Feb 18 11:07 ./
18964 drwxrwxrwt  6 root  wheel  1024 Feb 18 11:13 ../
19233 -rw-r--r--  1 jin   wheel    74 Feb 18 11:07 tp2u

# so far so good, the inode is the same (19232)

[41] FreeBSD-4.7: rm test/*
remove test/tp2u? y
[42] FreeBSD-4.7: ll -i test
total 4
19232 drwxr-xr-x  2 jin   wheel   512 Feb 18 11:13 ./
18964 drwxrwxrwt  6 root  wheel  1024 Feb 18 11:12 ../
# inode is still the same (19232)

[43] FreeBSD-4.7: !tar
tar -xvf x
test/
test/tp2u
[44] FreeBSD-4.7: ll -i test
total 6
19223 drwxr-xr-x  2 jin   wheel   512 Feb 18 11:07 ./
18964 drwxrwxrwt  6 root  wheel  1024 Feb 18 11:13 ../
19231 -rw-r--r--  1 jin   wheel    74 Feb 18 11:07 tp2u

# now test directory inode changed. Why?


>Fix:

	


>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: kris 
State-Changed-When: Mon Jul 14 03:53:06 PDT 2003 
State-Changed-Why:  
I am unable to reproduce this on -current or -stable. 
Can you confirm whether or not you still see this behaviour? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=48435 

From: Kris Kennaway <kris@obsecurity.org>
To: freebsd-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: kern/48435: wierd file system behavior
Date: Mon, 14 Jul 2003 14:34:57 -0700

 Adding to audit trail
 
 ----- Forwarded message from "Jin Guojun [NCS]" <j_guojun@lbl.gov> -----
 
 X-Original-To: kkenn@localhost
 Delivered-To: kkenn@localhost.obsecurity.org
 Delivered-To: kris@freebsd.org
 Date: Mon, 14 Jul 2003 13:20:53 -0700
 From: "Jin Guojun [NCS]" <j_guojun@lbl.gov>
 X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.8-RELEASE i386)
 X-Accept-Language: zh, zh-CN, en-US, en
 To: Kris Kennaway <kris@FreeBSD.org>
 Cc: freebsd-bugs@FreeBSD.org
 Subject: Re: kern/48435: wierd file system behavior
 X-UIDL: 2ce4fa2749ae0e2a7b7fff3fd76f1303
 X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=0.13.7.2
 
 Kris Kennaway wrote:
 
 > Synopsis: wierd file system behavior
 >
 > State-Changed-From-To: open->feedback
 > State-Changed-By: kris
 > State-Changed-When: Mon Jul 14 03:53:06 PDT 2003
 > State-Changed-Why:
 > I am unable to reproduce this on -current or -stable.
 > Can you confirm whether or not you still see this behaviour?
 >
 > http://www.freebsd.org/cgi/query-pr.cgi?pr=48435
 
 It seems still the same behavior.
 This may be the new feature for undelete a file ?
 which is only way I can guess that to change inode is useful.
 
 [312] 5.1lbl.gov:ll -i test
 total 24
 6338 drwxr-xr-x  2 jin   wheel   512 Jul 14 13:05 ./
    2 drwxrwxrwt  5 root  wheel   512 Jul 14 13:03 ../
 6340 -rw-r--r--  1 jin   wheel  2474 Jul 14 13:02 sshd_config
 [313] 5.1.lbl.gov: tar -xvf x
 test/
 test/sshd_config
 [314] 5.1.lbl.gov: ll -i test
 total 24
 6338 drwxr-xr-x  2 jin   wheel   512 Jul 14 13:06 ./
    2 drwxrwxrwt  5 root  wheel   512 Jul 14 13:03 ../
 6341 -rw-r--r--  1 jin   wheel  2474 Jul 14 13:02 sshd_config    # inode changed
 from 6340 to 6341
 
 [315] 5.1lbl.gov: rm test/sshd_config
 remove test/sshd_config? y
 [316] 5.1.lbl.gov: ll -i test
 total 16
 6338 drwxr-xr-x  2 jin   wheel  512 Jul 14 13:07 ./                           #
 inode is the same
    2 drwxrwxrwt  5 root  wheel  512 Jul 14 13:03 ../
 [317] 5.1.lbl.gov: !tar
 tar -xvf x
 test/
 test/sshd_config
 [318] 5.1.lbl.gov: ll -i test
 total 24
 2112 drwxr-xr-x  2 jin   wheel   512 Jul 14 13:02 ./                     #
 directory inode is changed
    2 drwxrwxrwt  5 root  wheel   512 Jul 14 13:07 ../
 2113 -rw-r--r--  1 jin   wheel  2474 Jul 14 13:02 sshd_config
 
 [319] 5.1.lbl.gov: uname -a
 FreeBSD 5.1.lbl.gov 5.1-RELEASE FreeBSD 5.1-RELEASE #2: Wed Jun 25 01:22:21 PDT
 2003
 
 --
 ------------ Jin Guojun ----------- v --- j_guojun@lbl.gov ---
 Distributed Systems Department          http://www.itg.lbl.gov/~jin
 M/S 50B-2239                            Ph#:(510) 486-7531 Fax: 486-6363
 Lawrence Berkeley National Laboratory,  Berkeley, CA 94720
 
 
 
 
 ----- End forwarded message -----

From: Kris Kennaway <kris@obsecurity.org>
To: "Jin Guojun [NCS]" <j_guojun@lbl.gov>,
	freebsd-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: kern/48435: wierd file system behavior
Date: Mon, 14 Jul 2003 14:35:47 -0700

 Please provide full details of your filesystem configuration and any
 nonstandard kernel configuration.
 
 Kris

From: Andy Farkas <andyf@speednet.com.au>
To: "Jin Guojun [NCS]" <j_guojun@lbl.gov>
Cc: Kris Kennaway <kris@freebsd.org>,
	<freebsd-gnats-submit@freebsd.org>
Subject: Re: kern/48435: wierd file system behavior
Date: Tue, 15 Jul 2003 08:43:57 +1000 (EST)

 I don't think this is a bug. Its what tar does.
 
 A truss of tar when the directory exists, but has no files:
 
 mkdir(0x809b070,0x1ed)		ERR#17 'File exists'
 unlink(0x809b070)		ERR#1 'Operation not permitted'
 rmdir(0x809b070)		= 0 (0x0)
 mkdir(0x809b070,0x1ed)		= 0 (0x0)
 
 But when a file exists in the directory:
 
 mkdir(0x809b070,0x1ed)          ERR#17 'File exists'
 unlink(0x809b070)		ERR#1 'Operation not permitted'
 rmdir(0x809b070)		ERR#66 'Directory not empty'
 
 So it seems tar is removing then creating the directory if it is empty.
 
 --
 
  :{ andyf@speednet.com.au
 
         Andy Farkas
     System Administrator
    Speednet Communications
  http://www.speednet.com.au/
 
 
 

From: "Jin Guojun [NCS]" <j_guojun@lbl.gov>
To: Andy Farkas <andyf@speednet.com.au>
Cc: Kris Kennaway <kris@freebsd.org>,
	freebsd-gnats-submit@freebsd.org
Subject: Re: kern/48435: wierd file system behavior
Date: Mon, 14 Jul 2003 16:04:33 -0700

 This was not a feature until 4.7-RELEASE.
 Also, I do not believe that other file system/UN*X does this.
 If this is not file system issue, but tar, then tar needs to be fixed.
 
 A couple of problems this behavior creates:
 (1) If a process is staying and running in this directory, it will be killed
 when directory (inode) is disappearing.
 (2) Fire off security alarm when a directory inode changed.
 
     -Jin
 
 Andy Farkas wrote:
 
 > I don't think this is a bug. Its what tar does.
 >
 > A truss of tar when the directory exists, but has no files:
 >
 > mkdir(0x809b070,0x1ed)          ERR#17 'File exists'
 > unlink(0x809b070)               ERR#1 'Operation not permitted'
 > rmdir(0x809b070)                = 0 (0x0)
 > mkdir(0x809b070,0x1ed)          = 0 (0x0)
 >
 > But when a file exists in the directory:
 >
 > mkdir(0x809b070,0x1ed)          ERR#17 'File exists'
 > unlink(0x809b070)               ERR#1 'Operation not permitted'
 > rmdir(0x809b070)                ERR#66 'Directory not empty'
 >
 > So it seems tar is removing then creating the directory if it is empty.
 >
 > --
 >
 >  :{ andyf@speednet.com.au
 >
 >         Andy Farkas
 >     System Administrator
 >    Speednet Communications
 >  http://www.speednet.com.au/
 

From: "Jin Guojun [NCS]" <j_guojun@lbl.gov>
To: Kris Kennaway <kris@obsecurity.org>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/48435: wierd file system behavior
Date: Mon, 14 Jul 2003 16:37:02 -0700

 Kris Kennaway wrote:
 
 > Please provide full details of your filesystem configuration and any
 > nonstandard kernel configuration.
 >
 > Kris
 
 It just basic GENERIC system. No special customer configuration.
 It happens with 4.7 through 5.1 on different hardware (M/B, IDE/SCSI,
 Intel/AMD). Two of them are list below:
 
 AMD/MP2000+ with IDE and SCSI + 4.8-R
 
 /dev/ad0s2a on / (ufs, local)
 /dev/da0s1e on /data (ufs, NFS exported, local, soft-updates)
 /dev/ad0s3g on /scratch (ufs, NFS exported, local, soft-updates)
 
 Intel/P4 3GHz with SCSI + 5.1-R
 
 /dev/aacd0s1a on / (ufs, local)
 devfs on /dev (devfs, local)
 /dev/md0 on /tmp (ufs, local, soft-updates)
 
 ------------ Jin Guojun ----------- v --- j_guojun@lbl.gov ---
 Distributed Systems Department          http://www.itg.lbl.gov/~jin
 M/S 50B-2239                            Ph#:(510) 486-7531 Fax: 486-6363
 Lawrence Berkeley National Laboratory,  Berkeley, CA 94720
 
 
 
State-Changed-From-To: feedback->open 
State-Changed-By: roam 
State-Changed-When: Tue Jul 15 01:01:26 PDT 2003 
State-Changed-Why:  
Submitter reports the problem still exists. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=48435 
State-Changed-From-To: open->closed 
State-Changed-By: kris 
State-Changed-When: Fri Oct 10 22:16:01 PDT 2003 
State-Changed-Why:  
It has been determined that this is deliberate behaviour by tar. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=48435 
>Unformatted:
