info-mtools
[Top][All Lists]
Advanced

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

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


From: Alain Knaff
Subject: Re: [Mtools] bug and fix: can't find a file/dir in a subdir
Date: Tue, 10 Feb 2009 00:13:45 +0100
User-agent: Thunderbird 2.0.0.19 (X11/20090105)

Mtools User Dave Aronson wrote:
> 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
> 

This is now fixed in 4.0.3, thanks for the note

Alain



reply via email to

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