[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Info-mtools] Bug: File or directory is lost after renaming it to "

From: David C Niemi
Subject: Re: [Info-mtools] Bug: File or directory is lost after renaming it to "Õtest"
Date: Sat, 30 Dec 2017 18:24:12 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0

Just got back from a little vacation. I was hoping to hear from Alain Knaff.  Given your information it should be easy enough to fix, but creating a proper release is not something I can do easily.


On 12/30/2017 08:09 AM, Pali Rohár wrote:
Hi David! Any progress on this problem?

On Sunday 19 November 2017 09:04:19 David C Niemi wrote:
Thanks for your diligent analysis of the problem.  I probably introduced
that bug back in about 1994...

Will need help from Alain to get this fix into a release.


On 11/17/2017 01:00 PM, Pali Rohár wrote:
Hi! More mtools programs (mlabel, mcopy, mdir) do not handle correctly
file names which starts with 0x05 or 0xE5 byte.

In FAT specification is written:

   * If DIR_Name[0] == 0xE5, then the directory entry is free (there is no
     file or directory name in this entry).

   * If DIR_Name[0] == 0x05, then the actual file name character for this
     byte is 0xE5.

Byte 0xE5 in CP850 is character 'Õ'. So if I try to create file which
starts with 'Õ', then mtools should convert 'Õ' to DOS codepage and if
it is 0xE5 then change it to 0x05.

But mtools does not change 0xE5 to 0x05 which leads to create orphaned
file. Test case for empty FAT filesystem:

$ echo test | mcopy - ::Õtest -i fat
$ mdir :: -i fat
Directory for ::/
No files

It is even worse when you try to rename directory to new name which
would start with 'Õ' character. After running mren the whole directory
which its content is lost:

$ mmd ::test -i fat
$ mdir :: -i fat
Directory for ::/
test         <DIR>     2017-11-17  18:46  test
$ mren ::test ::Õtest -i fat
$ mdir :: -i fat
Directory for ::/
No files

The problem is that mtools does not handle 0xE5 byte correctly and allow
user directly to damage directories entries.

Another program mlabel has exactly same problem:

$ mlabel ::test -i fat
$ mlabel -s ::test -i fat
   Volume label is TEST
$ mlabel ::Õtest -i fat
$ mlabel -s ::test -i fat
   Volume has no label

In attachment I'm sending fix for this bug.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]