info-mtools
[Top][All Lists]
Advanced

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

Re: [Info-mtools] Inconsistent results between kernel vfat and mtools; u


From: Nutchanon Wetchasit
Subject: Re: [Info-mtools] Inconsistent results between kernel vfat and mtools; user error indeed
Date: Tue, 21 Nov 2023 23:41:19 +0700

On Tue, 21 Nov 2023, Alexander Huemer wrote:

> mcopy -a ~/image.img -a :: .
[...]
> Does the image file have some unusual properties that push mtools to 
> undesired behavior?

Not "unusual" property at all, because:

> User error?

First, I suspect you are having at least some typos in the question,
for example: it shouldn't be `-a image.img` [1] but rather `-i ~/image.img`.

In any case, if you are really using `-a` switch with `mcopy`, then yes,
it is user error: because *you* are instructing it to attempt
translating CR-LF sequences into LF when copying the files;
which usually ruin the data in case of binary files.

This is an excerpt from Mtools manual, section "4.8 Mcopy" [2]:

> `a'
>      Text (ASCII) file transfer.  `ASCII' translates incoming carriage
>      return/line feeds to line feeds.

Of course, when you are mounting the same image using kernel Linux's
VFAT driver, it would be correct because it does none of such
file content translation by default. (And for what it's worth,
`mcopy` doesn't do such thing by default as well)

A reason you should NOT use `-a` switch with `mcopy` is more or less
the same reason you are NOT supposed use `conv=text` VFAT mount option [3]
which `man mount` already warned you about.

The minimally-correct `mcopy` command line for your use would rather be:

> $ mcopy -i ~/image.img -s :: .

(`-s` is for recursive copying)

You are free to add `-m` and/or `-p` switch to the command line
if you like of course too; which would not affect the resulting
files content's correctness. (They just improve metadata correctness)

And this is a demonstration of the minimally-correct invocation
using your example disk image (note that my temporary mount point path
at `/mnt/tmp` is a bit unconventional):

> # cd /tmp
> # ln -s IBM_3174_DSL_FC9021_N52.0.img image.img
> # mkdir /tmp/unpack
> # cd /tmp/unpack
> # /opt/mtools/bin/mcopy -i ../image.img -s :: .
> # mount -t vfat -o ro,loop /tmp/image.img /mnt/tmp
> # diff -u <(md5sum -b *) <(cd /mnt/tmp && md5sum -b *)
> # echo $?
> 0
> # 

You would see here that there is no difference whatsoever
in the files' content.

Regards,
Nutchanon Wetchasit
(Just another Mtools user)


GNU Mtools: 4.0.42 (source)
Kernel: Linux 3.2.63 (debian)
System: Debian GNU/Linux 7.0 "Wheezy" i386

-----

[1]
If you really did what you've written, `mcopy` would simply terminate with:

> Drive '::' not supported
> Cannot initialize '::'

[2]
Excerpt from Mtools 4.0.42's Texinfo manual; see `info mtools --index mcopy`
for your local version. `man mcopy` also works if you prefer that.
If you would rather like a WWW version, see:
https://www.gnu.org/software/mtools/manual/html_node/mcopy.html

[3]
Technically, if you try mounting using `conv=text` VFAT mount option,
you would find out in `dmesg` that kernel Linux even ignore
that option these days:
    
> FAT-fs (loop0): "conv=text" option is obsolete, not supported now

-- 
Use the manual, Luke.



reply via email to

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