udf folders pointing to self and above

udf folders pointing to self and above

[Pat LaVarre]

[-- Attachment #1: Type: text/plain, Size: 647 bytes --]

To create a place to collect what you & Google teach me over time, I
will go ahead and mention:

Often I find if I create an initially zero + `mkudffs` disk of 1 GiB,
the Philips udf verifier udf_test complains as follows.

...
    309 read block
EFE  file type DIR    name: "lost+found"
EFE  28  icbtag error: parentICBLocation: (34,0),
- recommended: (0,0) for strategy type 4.
- Icbtag Parent ICB Location shall not point to itself
- or to a higher parent in the directory hierarchy.
- ECMA 3rd edition 4/8.10.1, 4/14.6.7, UDF 2.3.5.3.
- icbtag: ECMA 4/14.6.*, 4/A.5, UDF 2.3.5.*, 6.6
- name: "lost+found"
EFE  216 Embedded data, 40 bytes
...


[-- Attachment #2: zlxudf.udfct_1.0r2.txt.bz2 --]
[-- Type: application/x-bzip, Size: 3939 bytes --]

Re: udf folders pointing to self and above

[Pat LaVarre]

Rather than to the open linux-scsi, this discussion might be occur where
open to users registered by daemon:

linux/fs/udf/ = linux_udf@hpesjro.fc.hp.com

Pat LaVarre

Re: udf folders pointing to self and above

[Randy.Dunlap]

On 29 Sep 2003 15:15:51 -0600 Pat LaVarre <p.lavarre@ieee.org> wrote:

| Rather than to the open linux-scsi, this discussion might be occur where
| open to users registered by daemon:
| 
| linux/fs/udf/ = linux_udf@hpesjro.fc.hp.com

Not that I want to register for another mailing list, but how would I
if I wanted to?

Pat, I think that you are getting the wrong message.
Linux filesystems (at least ones that are in the kernel tree) should be
discussed on open mailing lists.
OTOH, questions about user-space apps like zip not working on other
platforms are not kernel issues at all.

Granted that linux-scsi isn't the right place for linux filesystems
questions, but there is also linux-fsdevel@vger.kernel.org for that.

--
~Randy

Re: udf folders pointing to self and above

[Pat LaVarre]

> Linux filesystems ... in the kernel tree)
> should be discussed on open mailing lists [such as]
> linux-fsdevel@vger.kernel.org ...

Thanks for that prompt correction, sorry I needed it.  Accordingly now,

To linux-fsdevel@vger.kernel.org I have forwarded my post noting
"lost+found" "shall not point to itself or to a higher parent in the
directory hierarchy".

Sounds like I'm getting confused somewhere near finding udf-0.9.7/ and
linux/fs/udf/ simultaneously available.  Perhaps we intend for newbies
to use udftools-1.0.0b2/ together with linux/fs/udf/ no matter that
udftools-1.0.0b2/ appears together with udf-0.9.7/.

Or maybe we're not supposed to use the udftools-1.0.0b2/mkudffs/mkudffs
that mostly works.  Maybe we're supposed to begin by discovering how to
overcome:

$ uname -r
2.6.0...
$ sudo /sbin/mkfs -t udf /dev/loop0
mkfs.udf: No such file or directory
$

Pat LaVarre

Re: udf folders pointing to self and above

[Pat LaVarre]

> > Linux filesystems ... in the kernel tree)
> > should be discussed on open mailing lists [such as]
> > linux-fsdevel@vger.kernel.org ...

usb-storage kindly reminds me in part I may have got the idea that we
maintain udf.ko outside of linux-fsdevel by way of kernel.org releasing
2.6.0-test6 Without benefit of the perhaps incorrect patch:

--- linux-2.6.0-test6/MAINTAINERS	2003-09-27 18:50:29.000000000 -0600
+++ linux/MAINTAINERS	2003-09-29 16:44:27.250110640 -0600
@@ -1973,12 +1973,12 @@
 UDF FILESYSTEM
 P:	Ben Fennema
 M:	bfennema@falcon.csc.calpoly.edu
 P:	Dave Boynton
 M:	dave@trylinux.com
-L:	linux_udf@hpesjro.fc.hp.com
-W:	http://linux-udf.sourceforge.net
+L:	linux-fsdevel@vger.kernel.org
+W:	http://www.kernel.org
 S:	Maintained
 
 UMSDOS FILESYSTEM
 P:	Matija Nalis
 M:	Matija Nalis <mnalis-umsdos@voyager.hr>

Re: udf folders pointing to self and above

[Pat LaVarre]

> the idea that we maintain udf.ko outside of linux-fsdevel

Also I see the binary points us away from linux-fsdevel:

$
$ dd if=/dev/zero of=dd.bin bs=1M seek=0 count=1
1+0 records in
1+0 records out
$ sudo losetup /dev/loop0 dd.bin
$ sudo mkudffs /dev/loop0 | tail -1
start=511, blocks=1, type=ANCHOR
$ sync
$ sudo losetup -d /dev/loop0
$ strings dd.bin | grep @ | uniq
<linux_udf@hpesjro.fc.hp.com>
$

I haven't yet found a google archive of linux_udf@hpesjro.fc.hp.com.

Pat LaVarre