info-mtools
[Top][All Lists]
Advanced

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

[Mtools] bug and fix: can't find a file/dir in a subdir


From: Mtools User Dave Aronson
Subject: [Mtools] bug and fix: can't find a file/dir in a subdir
Date: Thu, 5 Feb 2009 13:29:08 -0500

Hi y'all!  Long time mtools user, first time bugfixer.  ;-)

I've run across a bug that was introduced sometime between
3.9.11-2.fc8 (which I yummed onto my FC box), and 4.0.1, for which I
downloaded the code so I could port it to another platform.   (STOP on
an XTS, if anybody knows/cares what that is.  Google it if you're
curious, email me if you then want more info.)

The symptoms are twofold:

1)  mtools will not find a file or directory in a subdirectory.  For
instance, say you've got a dir hierarchy including
a:/test/test2/test3/test4/test5, with a file called foo.# at each step
(i.e., a:/test/foo, a:/test/test2/foo.2, etc.).  mdir a:/test will
succeed, but mdir a:/test/foo will fail.  Likewise, mcd a:/test
followed by mdir foo will succeed, but then mdir a:test2/foo.2 will
fail, as will mcd a:test2/test3.  Regardless of what prior mcd's
you've done, mcd a:/test/test2 will fail.

2)  When you've already mcd'ed to a directory at least two levels deep
(which you'd have to do one at a time), the next time you try to
access the device, mtools "forgets" where you were, i.e., deletes
~/.mcwd, and pretends you were at the device root.

The cause is at line 591 of vfat.c.  Patch, as output by svn diff:

Index: vfat.c
===================================================================
--- vfat.c      (revision 3741)
+++ vfat.c      (working copy)
@@ -588,8 +588,11 @@
                length = strlen(filename);

        if(filename != NULL)
-               length = native_to_wchar(filename, wfilename, MAX_VNAMELEN+1,
+        {
+                if (length > MAX_VNAMELEN) length = MAX_VNAMELEN;
+               length = native_to_wchar(filename, wfilename, length,
                                         0, 0);
+        }

At this point, mtools has already determined the length of the
immediate chunk of filename it wants to work on.  For instance, if
you're doing mcd a:/test/test2/test3, at the first time this point is
hit, filename is test/test2/test3 and length is 4, so as to work on
just "test" at that point.  However, if native_to_wchar receives
MAX_VNAMELEN+1, it will gladly work on the whole thing, and return 15.
 So, anything further will be looking for a single file or dir, among
the entries in the root dir, named "test/test2/test3", which will
fail.

This lookup is done both for the current dir (i.e., contents of
~/.mcwd) if there is one, and for whatever file/directory you're
looking for.  So, if you're already mcd'ed to a:/test/test2, OR you're
trying to mdir a:/test/test2, this will fail.

The fix passes native_to_wchar, the length that mtools already knows.
I haven't bothered tracing back to see if there's any possibility that
it could be greater than MAX_VNAMELEN, so I've put a guard test there
Just In Case, thus making it also need the braces.

I've verified that this works on my other platform.  Haven't tried it
on Linux, but see no reason why it shouldn't.  Even if not, you're no
worse off, since I've verified that the distributed tarball doesn't.
:-)

-Dave

-- 
Dave Aronson: Have Pun, Will Babble | Work: davearonson.com | /\ ASCII
------------------------------------| Play: davearonson.net | \/ Ribbon
"Specialization is for insects."    | Life: dare2xl.com     | /\ Campaign
-Robert A. Heinlein                 | Wife: nasjleti.net    | Email<>Web


reply via email to

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