From owner-freebsd-bugs@FreeBSD.ORG Mon Mar 16 21:30:38 2015 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A9832B6 for ; Mon, 16 Mar 2015 21:30:38 +0000 (UTC) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D836DA0F for ; Mon, 16 Mar 2015 21:30:37 +0000 (UTC) Received: by iegc3 with SMTP id c3so186218561ieg.3 for ; Mon, 16 Mar 2015 14:30:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:subject:mime-version :content-type; bh=VA1oWVmBv6e2AIB8Oyt8PNB7U/n036aE6sP4Fu3dvIU=; b=lXy6IKdgTCcKpFUG04K7Pz0egZVIMp+Kgm6DcDzNmQicCOaBBu3rAtP5TaNGtzHZAg dc6iMYIRnploPC/neb8WLaCvrn9Q7PfTY5FQYE95gCbijXVGbYF0/gLSg0QiNUK5Q8zr un1G8WzNUQOD5iH6CfR7m1QhNVlbhl88YctsKAl5DsaILazK/ORiljQemLXuD3az/Heh xgPj8HSoJZUt2+DkTbphMexpC3oH7Ypg2ryq9c3lS6GiadgS5B605ZD739mUrpr3fPoT EVa/DzTM+0bnvfQfp6OEbcs23JrHXJHl67k0C0+WkvELVpwUszlc9saEug4u0d90alnS 6c5w== X-Gm-Message-State: ALoCoQkYKjTuZSNdqSXNQI3gzFMZODvQ5R99+cYTbLMl6lXwgLSY3xaC36R8p565c9OQk1xfy7i9 X-Received: by 10.42.238.140 with SMTP id ks12mr20343593icb.12.1426541430437; Mon, 16 Mar 2015 14:30:30 -0700 (PDT) Received: from [2601:1:c080:2c0f:7058:678e:100::] ([2601:1:c080:2c0f::101]) by mx.google.com with ESMTPSA id gz4sm7485591igb.19.2015.03.16.14.30.29 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 16 Mar 2015 14:30:30 -0700 (PDT) Date: Mon, 16 Mar 2015 15:30:28 -0600 From: Mattias Lindgren To: freebsd-bugs@freebsd.org Message-ID: <3D6E6D4313774D30AE2F4C7BB7AC2156@runelind.net> Subject: Schroedingers files. Both there and not there. X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 21:30:38 -0000 I=E2=80=99ve been having some issues over the past few months that I=E2=80= =99m finally getting around to troubleshooting. I=E2=80=99m running =46re= eBSD 10.1-p5 with Z=46S. My nightly emails have been giving me output li= ke: Checking setuid files and devices: find: /usr/include/dev/an=5Fbak/if=5Faironet=5Fieee.h: No such file or di= rectory Checking negative group permissions: find: /usr/include/dev/an=5Fbak/if=5Faironet=5Fieee.h: No such file or di= rectory The reason for it being called an=5Fbak is that the original file used to= have the same errors, so I moved that directory and extracted a known go= od version of if=5Faironet=5Fieee.h. However now I=E2=80=99d just like to= clean out the bad file. =20 If I do an rm -rf on the file, it kicks me back to the command prompt lik= e everything worked successfully, however if I ls that directory, it stil= l shows up: =24 ls /usr/include/dev/an=5Fbak/ if=5Faironet=5Fieee.h =24 sudo rm -rf /= usr/include/dev/an=5Fbak/if=5Faironet=5Fieee.h =24 ls /usr/include/dev/an= =5Fbak/ if=5Faironet=5Fieee.h However, ls -al shows a different output: =24 ls -al /usr/include/dev/an=5Fbak/ ls: if=5Faironet=5Fieee.h: No such = file or directory total 17 drwxr-xr-x 2 root wheel 3 Dec 21 20:32 . drwxr= -xr-x 31 root wheel 31 Mar 16 15:26 .. I can move the an=5Fbak folder to a different name within the same pool. = However I cannot move that folder to a different zfs pool. I can not move= just the file, either within the same pool or to a different pool. This is only one of the files that is giving me the problem, the daily ou= tput also lists a few others, but they all exhibit the same behavior. I tried sending the zfs dataset to another pool, and it exhibited the sam= e problem. A scrub has not revealed any issues. =20 Thanks, Mattias