Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 3 Nov 2012 21:38:49 +1100
From:      Peter Jeremy <peter@rulingia.com>
To:        Garrett Cooper <yanegomi@gmail.com>
Cc:        FreeBSD FS <freebsd-fs@freebsd.org>
Subject:   Re: Inconsistent/potentially incorrect behavior with relative lookups via chdir(2) on UFS/ZFS
Message-ID:  <20121103103849.GD12996@server.rulingia.com>
In-Reply-To: <CAGH67wSa7y-Nz=Pm%2BpxL3TRyKvBdDq2s3paSCu3LB-AFwmO_2g@mail.gmail.com>
References:  <CAGH67wSa7y-Nz=Pm%2BpxL3TRyKvBdDq2s3paSCu3LB-AFwmO_2g@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--tjCHc7DPkfUGtrlw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2012-Nov-01 15:25:05 -0700, Garrett Cooper <yanegomi@gmail.com> wrote:
>    Just doing some interop testing on UFS/ZFS to develop a baseline for
>filesystem behavior, and I noticed some inconsistencies with the ENOENT
>requirement in chdir(2) when dealing with relative ".." paths (dot-dot
>lookups). In particular...
>    1. I would have expected chdir('.') to have failed in UFS/ZFS with
>ENOENT if '.' wasn't present, but it didn't.
>    2. I would have expected chdir('..') to have failed in ZFS with ENOENT
>if '..' wasn't present, but it didn't.
>    Sidenote: python doesn't do any special handling with os.chdir, per
>Modules/posixmodule.c (I checked).
>    The full test I ran is included below.

Whilst playing with the above, I've found some wierd timing issues
with UFS+SU:

$ mkdir -p ~/p/q/r;sync
$ cd p/q/r
$ rm -r ~/p; while date; do sleep 3 ; ls -al;done
Sat  3 Nov 2012 21:29:19 EST
total 2
drwxr-xr-x  0 peter  jeremy  512  3 Nov 21:28 .
drwxr-xr-x  0 peter  jeremy    0  3 Nov 21:29 ..
Sat  3 Nov 2012 21:29:22 EST
total 2
drwxr-xr-x  0 peter  jeremy  512  3 Nov 21:28 .
drwxr-xr-x  0 peter  jeremy    0  3 Nov 21:29 ..
Sat  3 Nov 2012 21:29:25 EST
total 2
drwxr-xr-x  0 peter  jeremy  512  3 Nov 21:28 .
drwxr-xr-x  0 peter  jeremy    0  3 Nov 21:29 ..
Sat  3 Nov 2012 21:29:28 EST
total 2
drwxr-xr-x  0 peter  jeremy  512  3 Nov 21:28 .
drwxr-xr-x  0 peter  jeremy    0  3 Nov 21:29 ..
Sat  3 Nov 2012 21:29:31 EST
total 2
drwxr-xr-x  0 peter  jeremy  512  3 Nov 21:28 .
drwxr-xr-x  0 peter  jeremy    0  3 Nov 21:29 ..
Sat  3 Nov 2012 21:29:34 EST
total 2
drwxr-xr-x  0 peter  jeremy  512  3 Nov 21:28 .
drwxr-xr-x  0 peter  jeremy    0  3 Nov 21:29 ..
Sat  3 Nov 2012 21:29:37 EST
total 2
drwxr-xr-x  0 peter  jeremy  512  3 Nov 21:28 .
drwxr-xr-x  0 peter  jeremy    0  3 Nov 21:29 ..
Sat  3 Nov 2012 21:29:40 EST
total 2
drwxr-xr-x  0 peter  jeremy  512  3 Nov 21:28 .
drwxr-xr-x  0 peter  jeremy    0  3 Nov 21:29 ..
Sat  3 Nov 2012 21:29:43 EST
total 2
drwxr-xr-x  0 peter  jeremy  512  3 Nov 21:28 .
drwxr-xr-x  0 peter  jeremy    0  3 Nov 21:29 ..
Sat  3 Nov 2012 21:29:46 EST
total 0
Sat  3 Nov 2012 21:29:49 EST


--=20
Peter Jeremy

--tjCHc7DPkfUGtrlw
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)

iEYEARECAAYFAlCU9DkACgkQ/opHv/APuIeaLwCgkB8JgG9tSfydF3USTldqC2lF
qMgAnidEXpy1og79YMoP/EredHHaDHfI
=pnFO
-----END PGP SIGNATURE-----

--tjCHc7DPkfUGtrlw--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121103103849.GD12996>