Kernel bug tracker

[Thomas Schmitt]

Hi,

Valdis Klētnieks wrote:
> The tricky part is, of course, that for this to work correctly, you need
> to have 64-bit timestamps in the on-disk format.

Initially yes. In
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800627
i sketched what it thought was needed to do.
But by the much more elegant

  https://github.com/torvalds/linux/commit/34be4dbf87fc

the full ISO 9660 date range up to year 2155 would be correctly shown,
if not in year 2038 signed int would roll over.
Demo:

  xorriso -outdev /tmp/test_date.iso \
          -blank as_needed \
          -map /bin/true /victim \
          -alter_date m 'Oct 01 22:06:12 2040' /victim --

  mount /tmp/test_date.iso /mnt/iso
  ls -l /mnt/iso/victim

yields currently

  ... Aug 26  1904 /mnt/iso/victim

But after the really simple change to time64_t it yields

  ... Oct  1  2040 /mnt/iso/victim

So this is really a low hanging fruit in fs.
Still there today in the torvalds Github repo.

------------------------------------------------------------------------

> > - isofs: truncate oversized Rock Ridge names to 255 bytes
> >   Map trailing incomplete UTF-8 bytes to '_'.

> A better answer would probably be to truncate it at the last complete UTF-8
> that leaves the string at 255 or less.

My patch proposal could be changed accordingly.
But with '_' as placeholders of bytes from incomplete UTF-8 characters
there would be a distinction to names with the same start bytes but ending
directly before the UTF-8 character which got cut apart.

The need for real truncation should rarely occur. Main motivation for
fixing this would be this observation:

Currently Rock Ridge names of length >= 254 are coarsely truncated by
discarding the whole NM entry where the overflow happened. This yields
name lengths of much less than the permissible 255 bytes.
There is no reason to see why to exclude length 254 and 255 and especially
to truncate by possibly a hundred or more bytes than necessary.

File names in ISO 9660 + Rock Ridge ISO

  1234567890...230.more.bytes...12345678901234E
  ääääääääää...210.more.bytes...ääääääääääxää

get shown after mount(8) in xterm with bash by /bin/ls as

   12345678901234567890...60.more.bytes...1234567890123
  'ääääääääääääääääääääääääääääääääääääääääääääää'$'\303'

Note the leading blank with the plain ASCII name and the shell characters
with the name that has 2-byte UTF-8 characters.

(Rock Ridge encodes its names in one or more NM entries. Long names often
get split between a NM in the file's ISO 9660 directory record and a NM
in the Contiuation Area of the file. That second one gets dropped.)

Other than the time rollover fix, this problem needs some knowledge about
ISO 9660, which is available for free as ECMA-119, and about SUSP + RRIP
of which specs are available for free too.
Both are really simple, compared with e.g. UDF specs.

I am ready to explain in detail what is neded to understand the problem.
If Adverg Ebashinskii wants, i'll hand over my patch as guideline, or as
base for own work, or just for review, testing, and posting.
I can give instructions how to reproduce each of the three bugs by help
of small ISO images made with xorriso.


Have a nice day :)

Thomas