[Top][All Lists]
[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