Hi, Well, KDE Partition Manager uses dosfstools but I can always release a new version once updated dosfstools is released. Best, Andrius 2017 m. lapkričio 5 d., sekmadienis 13:56:53 GMT Andy Shevchenko rašė: > On Sun, Nov 5, 2017 at 3:39 PM, Pali Rohár wrote: > > On Tuesday 31 October 2017 10:35:48 Andy Shevchenko wrote: > >> On Mon, Oct 16, 2017 at 4:12 AM, Andreas Bombe wrote: > >> > On Thu, Oct 12, 2017 at 10:49:31PM +0200, Pali Rohár wrote: > >> >> On Thursday 12 October 2017 12:13:11 Karel Zak wrote: > > >> > I was worried that there might be some scripts or programs that expect > >> > >> If we really care about such scripts another approach might be to > >> introduce a CLI switch to "spec compatible mode" to each tool and > >> suggest in documentation to use it. > >> > >> There are also variants: > >> - spec compatible > >> - WinXX compatible > >> - DOS compatible > >> - etc > > > > I did tests with MS-DOS and Windows versions (results in previous > > email), and they seems to be compatible how they read label. > > > > Based on results I would suggest to ignore label from the boot sector > > when reading label. > > So, for tools which are not doing that to add > > --ignore-boot-sector-label (or alike) [recommended] > > right? > > We don't actually know how many users (scripts) are relying on current > behaviour. > If there are only few, we may introduce backward compatibility switch > > --read-boot-sector-label > > > This makes behavior consistent with older MS-DOS > > systems and also all Windows systems. This change would be a problem > > only for users who have label stored only in boot sector. After change > > they would not see label anymore -- exactly same what MS-DOS or Windows > > show them. Seems that mkdosfs stores label to both location, since > > support for label was introduced. So different label would be visible > > only for users who used dosfslabel prior to version 3.0.16. > > > > What do you think? > > So, in summary it looks like a documentation needs update (to mark > your research). > > -- I encourage the use of end to end email encryption GPG key: https://stikonas.eu/andrius.asc Fingerprint: 1EE5 A320 5904 BAA2 B88C 0A9D 24FD 3194 0095 C0E1