Re:In memoriam Joerg Schilling

[王锋]

R.I.P. This is so sad.


Feng Wang

--原始邮件--
发件人："Thomas Schmitt "

Re: Extended attributes support on udf file system

[王锋]

Hi Jörg,


 Hi all,

 Is there any tool which can create udf file system image supporting 
extended attributes? I tried mkudffs and mkisofs, but they all failed.

 Hi,

 what do you expect?

 Since August 2006 mkisofs suports extended attributes for Mac OS.

 Is this what you like?

 Do you use the real mkisofs or one of the fake/outdated variants?

On linux platform I'd like to create an udf image and mount it to a directory, 
then copy some files with extended attributes to the image. I hope the 
extended attributes to be reserved on the udf file system.


The version of mkisofs I used is "mkisofs 3.02a10 2020/02/26 
(x86_64-unknown-linux-gnu)". The following is what I did with mkisofs.


#Check the version of mkisofs
root@Ubuntu:x86_64-linux-gcc# ./mkisofs --version
mkisofs 3.02a10 2020/02/26 (x86_64-unknown-linux-gnu)


Copyright (C) 1993-1997 Eric Youngdale
Copyright (C) 1997-2019 Joerg Schilling
Copyright (C) 1997-2001 James Pearson
Copyright (C) 2006   HELIOS Software GmbH


#Set the extended attribute to the file.
root@Ubuntu:x86_64-linux-gcc# setfattr -n "trusted.udf.test" -v "1234" 
./100M-file
root@Ubuntu:x86_64-linux-gcc# getfattr -d -m .* ./100M-file
# file: 100M-file
trusted.udf.test="1234"


#Make the udf image file
root@Ubuntu:x86_64-linux-gcc# ./mkisofs -o /tmp/a.udf -udf ./100M-file 

 9.69% done, estimate finish Fri Mar 20 21:09:54 2020
19.43% done, estimate finish Fri Mar 20 21:09:54 2020
29.10% done, estimate finish Fri Mar 20 21:09:54 2020
38.77% done, estimate finish Fri Mar 20 21:09:54 2020
48.44% done, estimate finish Fri Mar 20 21:09:54 2020
58.17% done, estimate finish Fri Mar 20 21:09:54 2020
67.84% done, estimate finish Fri Mar 20 21:09:54 2020
77.51% done, estimate finish Fri Mar 20 21:09:54 2020
87.18% done, estimate finish Fri Mar 20 21:09:54 2020
96.92% done, estimate finish Fri Mar 20 21:09:54 2020
Total translation table size: 0
Total rockridge attributes bytes: 0
Total directory bytes: 0
Path table size(bytes): 10
Max brk space used 0
51618 extents written (100 MB)
root@Ubuntu:x86_64-linux-gcc# mount /tmp/a.udf /mnt
mount: block device /tmp/a.udf is write-protected, mounting read-only


#Check the extended the attribute after mount the image file. But we got 
nothing.
root@Ubuntu:x86_64-linux-gcc# getfattr -d -m .* /mnt/100M-file  
   

root@Ubuntu:x86_64-linux-gcc#




The extended attribute is lost.


---


For the mkudffs I got the error with "Operation not supported" message.


root@Ubuntu:x86_64-linux-gcc# mkudffs -h
mkudffs 1.0.0b2 for UDF FS 1.0.0-cvs, 2002/02/09



root@Ubuntu:x86_64-linux-gcc# truncate -s 150M a.udf
root@Ubuntu:x86_64-linux-gcc# mkudffs ./a.udf
start=0, blocks=16, type=RESERVED
start=16, blocks=3, type=VRS
start=19, blocks=237, type=USPACE
start=256, blocks=1, type=ANCHOR
start=257, blocks=16, type=PVDS
start=273, blocks=1, type=LVID
start=274, blocks=76269, type=PSPACE
start=76543, blocks=1, type=ANCHOR
start=76544, blocks=239, type=USPACE
start=76783, blocks=16, type=RVDS
start=76799, blocks=1, type=ANCHOR





root@Ubuntu:x86_64-linux-gcc# getfattr -d -m .* ./100M-file   
   
   
# file: 100M-file
trusted.udf.test="1234"
root@Ubuntu:x86_64-linux-gcc# cp --preserve ./100M-file /mnt/
root@Ubuntu:x86_64-linux-gcc# getfattr -d -m .* /mnt/100M-file
root@Ubuntu:x86_64-linux-gcc# setfattr -n "trusted.udf.test" -v "1234" 
/mnt/100M-file
setfattr: /mnt/100M-file: Operation not supported





According to the specification of UDF version 2.01, this feature should be 
supported. Is there something wrong with what I did?


Best Regards,
WF

Extended attributes support on udf file system

[王锋]

Hi all,


Is there any tool which can create udf file system image supporting extended 
attributes? I tried mkudffs and mkisofs, but they all failed.


Best Regards,
Feng Wang

Re: How to create a proper size UDF image?

[王锋]

Hi Jörg,


This patch works. All the file names can be read successfully. Thank you.
But the longest name is truncated by one char without any warning message. 
IMHO, it's better to add an option that those too long names are reported 
instead of being truncated directly.




--
WF
 

 
 
 
-- Original --
From:  "Joerg Schilling";
Date:  Thu, Jan 25, 2018 02:01 AM
To:  "feng.wang"; "cdwrite"; 

Subject:  Re: How to create a proper size UDF image?

 
??  wrote:

> Hi Jörg,
>
>
> > I just verified that your problem is also present on Solaris, so I would 
> > need to 
> fix it in mkisofs.
>
> > This may take a few days, as I need to understand what's happening when 
> > there 
> are more than 2 of these characters

Hi, could you test this patch:


--- joliet.c ---
--- /tmp/sccs.D8aOtz2015-12-30 19:04:32.953572000 +0100
+++ joliet.c2018-01-24 19:00:01.459473000 +0100
@@ -257,6 +257,8 @@
unsigned char   uc;
int jsize = size;
 
+   jsize = strlen(source);
+
/*
 * If we get a NULL pointer for the source, it means we have an
 * inplace copy, and we need to make a temporary working copy first.
@@ -344,6 +346,8 @@
unichar = '_';
}
all_chars:
+   if (unichar == 0)
+   unichar = '_';
;
}
buffer[i] = unichar >> 8 & 0xFF; /* final UNICODE */


Jörg

-- 
 EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin
joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/file

Re: How to create a proper size UDF image?

[王锋]

Hi Jörg,


> I just verified that your problem is also present on Solaris, so I would need 
> to 
fix it in mkisofs.

> This may take a few days, as I need to understand what's happening when there 
are more than 2 of these characters

That's OK. Many thanks for your help.


--
WF

Re: How to create a proper size UDF image?

[王锋]

Hi Jörg,


>>
>> But I find the Chinese characters (UTF-8 charset) are not supported very 
>> well. The commands I used are the following. 
>> root@Ubuntu:~# ls long-name/
>> ?.1
>> ??.2
>> ???.3
>> .4
>> ?.5
>> ??.6

> Could you please mention the hex code for that chinese character?

The hex code  is "4E2D". 

>> ... ...
>> root@Ubuntu:~# /opt/schily/bin/mkisofs -UDF -o a.udf ./long-name
>> Setting input-charset to 'UTF-8' from locale.
>> Total translation table size: 0
>> Total rockridge attributes bytes: 0
>> Total directory bytes: 0
>> Path table size(bytes): 10
>> Max brk space used 0
>> 507 extents written (0 MB)
>>
>>
>> root@Ubuntu:~# mount ./a.udf /mnt   
>> mount /root/a.udf 
>>
>>
>> root@Ubuntu:~# ls /mnt
>> ?.1
>> ??.2
>> ???#00A6._
>> _#D14D
>> ?_#7C02
>> ??_#8F1A
>>
>>..
>>
>>
>> We can see that some filenames cannot be read correctly.

> What OS did you use to mount the filesystem?
> Are you sure that the OS is bug free?

I am using an old ubuntu system with the kernel version 3.13.0-100-generic.

> Could you provide a tar archive that contains the files (0 bytes for each is 
OK)?

Yes, I just created these files using "touch" command. Please find the attached 
tar file.

> > > mkisofs -UDF -print-size
>>
>> > gives you the size.
>
>
>> Well that's what I want. It's really useful feature. Does it count the size 
>> of entries? I mean that one directory may have thousands small files. The 
>> directory's entry size cannot be negligible. 


> This is the number of 2048 byte blocks that will be in the FS image in total.


OK. 

--
WF

long-name.tgz
Description: Binary data

Re: How to create a proper size UDF image?

[王锋]

Hi Jörg,
 

??  wrote:


>> I know that some tools like mkisofs could make files to a udf image directly 
>> with efficient size. However the size created by mkisofs could be larger 
>> than the media size. What's more, the udf filesystem made by mkisofs is a 
>> UDF hybrid and not a UDF only filesystem.   

> Why do you have a problem with a hybrid?
> This usually does not increase the size in a way that is relevant.

I once used mkisofs but it did not support uid and gid. Now I update it to the 
latest version (3.02a09),  this problem is resolved. 


But I find the Chinese characters (UTF-8 charset) are not supported very well. 
The commands I used are the following. 
root@Ubuntu:~# ls long-name/
中.1
中中.2
中中中.3
.4
中.5
中中.6

... ...
root@Ubuntu:~# /opt/schily/bin/mkisofs -UDF -o a.udf ./long-name
Setting input-charset to 'UTF-8' from locale.
Total translation table size: 0
Total rockridge attributes bytes: 0
Total directory bytes: 0
Path table size(bytes): 10
Max brk space used 0
507 extents written (0 MB)


root@Ubuntu:~# mount ./a.udf /mnt   
mount：块设备 /root/a.udf 写保护，将以只读方式挂载


root@Ubuntu:~# ls /mnt
中.1
中中.2
中中中#00A6._
_#D14D
中_#7C02
中中_#8F1A

..


We can see that some filenames cannot be read correctly.



>> So is there a rational method to get the rough size of a UDF image file to 
>> be created if we know the directory tree and sizes of files needed to be 
>> burned? I think 10% larger size  overhead could be acceptable. 

> I recommend to use mkisofs, as this creates a proper readonly UDF.

> mkisofs -UDF -print-size

> gives you the size.


Well that's what I want. It's really useful feature. Does it count the size of 
entries? I mean that one directory may have thousands small files. The 
directory's entry size cannot be negligible. 






--
WF

How to create a proper size UDF image?

[王锋]

Hi all,


If we'd like to burn some data files using UDF file system, normally we should 
firstly make a UDF loop file and copy files into it.
The size of UDF file is a headache because it is not same with the size given 
by du. Actually the du size is calculated by the file system which the files to 
be burned are located. In some conditions, the two sizes are different very 
large. For example I created about 150K zero-size files using touch on the ext4 
file system. The du size is only 3.5MB compared with 300MB udf file size.


On the other size, it is not acceptable to create a udf file with the size of 
media disc. The empty session not used in the file can increase the burning 
time.


I know that some tools like mkisofs could make files to a udf image directly 
with efficient size. However the size created by mkisofs could be larger than 
the media size. What's more, the udf filesystem made by mkisofs is a UDF hybrid 
and not a UDF only filesystem.   


So is there a rational method to get the rough size of a UDF image file to be 
created if we know the directory tree and sizes of files needed to be burned? I 
think 10% larger size  overhead could be acceptable. 




--
WF

Re: Could BD-RE disc come back to un-formatted state?

[王锋]

Hi Thomas,


Many thanks for your reply. The use case is that BD-RE discs need recycling to 
be reused again.  Currently I use dd to nullify the first 64KB to quickly clean 
the udf filesystem built on the BD-RE disc. But this state is different with 
the original blank state.  So the state switch of BD-RE disc is:
blank -> formatted -> filesystem -> formatted


In the "blank" and "formatted" states the disc actually cannot be used by users 
directly.  The hardware media states of "formatted" and "filestystem" are the 
same "complete".  I'd like to unify the "blank" and  "formatted" status to one 
state and make it different with the "filesystem" state.


Since it cannot be deformatted back to blank state regularly, I have to use 
"lsblk -o FSTYPE" to classify the "formatted" and "filesystem" states. Do you 
have any suggestion on this?
Your burner which could deformat BD-RE disc is really funny :-)



--
WF
 

 
 
 
-- Original --
From:  "Thomas Schmitt";
Date:  Wed, Jan 3, 2018 04:52 PM
To:  "feng.wang"; 

Subject:  Re: Could BD-RE disc come back to un-formatted state?

 
Hi,

> After being formatted, the BD-RE disc is changed to "complete" from "blank"
> status. Could we change the status back to "blank"?

Not regularly. The SCSI/MMC command set for optical media offers no
opportunity to deformat a BD-RE medium. One may only change the size of the
Spare Area.

Said this, i have an old BD burner which can do the trick by accident:
"Optiarc", model "BD RW BD-5300S", firmware "1.04".
If i insert and remove a CD-R medium then it afterwards deformats any BD-RE
medium i give to it and refuses to write them. A power-off-on cycle brings
it back to normal operation.
The affected media have to be formatted again before they can be written.


> According to the
> thread https://lists.debian.org/cdwrite/2010/02/msg00014.html, the
> "dvd+rw-format -blank" command is useless to change the status back to
> "blank". 

Indeed. The "-blank" option only applies to DVD-RW media. Those can be
de-formatted from overwritable state to sequential "blank" state (or
erased from sequential states "appendable" or "closed" to "blank").

My program xorriso extends the model of "blank", "appendable", and "closed"
to ISO 9660 sessions on overwritable media like BD-RE. Valid ISO 9660
filesystems do not get overwritten by xorriso unless they get devalidated
by a xorriso "-blank" command.
But that is only a content-orient classification. The hardware state of
such media stays "complete" and no writing can be done before the medium
gets formatted to that state.


What is your use case for which you need to de-format the BD-RE medium ?
Why would a formatted BD-RE not work for this use case ?


Have a nice day :)

Thomas