From owner-freebsd-questions@FreeBSD.ORG Tue Sep 27 21:11:17 2005 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B85D16A41F for ; Tue, 27 Sep 2005 21:11:17 +0000 (GMT) (envelope-from micahjon@ywave.com) Received: from smtpout1.ywave.com (ycomradius.yelmtel.com [216.227.100.60]) by mx1.FreeBSD.org (Postfix) with SMTP id 93C7543D5D for ; Tue, 27 Sep 2005 21:11:16 +0000 (GMT) (envelope-from micahjon@ywave.com) Received: (qmail 3634 invoked by uid 502); 27 Sep 2005 21:11:15 -0000 Received: from dsl-12-178-99-132.ywave.com (HELO ?192.168.1.65?) (micahjon@ywave.com@12.178.99.132) by 0 with SMTP; 27 Sep 2005 21:11:15 -0000 X-CLIENT-IP: 12.178.99.132 X-CLIENT-HOST: dsl-12-178-99-132.ywave.com Message-ID: <4339B572.9010405@ywave.com> Date: Tue, 27 Sep 2005 14:11:14 -0700 From: Micah User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050924) X-Accept-Language: en-us, en MIME-Version: 1.0 To: martinko References: <433852A8.10900@gish.demon.nl> <200509271532.34672.list-freebsd-2004@morbius.sent.com> <43395D89.8080208@ywave.com> <200509271635.20815.list-freebsd-2004@morbius.sent.com> <4339A1D6.7020708@ywave.com> <4339B4AE.80205@pobox.sk> In-Reply-To: <4339B4AE.80205@pobox.sk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-questions@freebsd.org Subject: Re: file name case issue on fat32 (Was: Re: Sharing data files on a dual-boot machine ...) X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2005 21:11:17 -0000 martinko wrote: > Micah wrote: > >> >> >> RW wrote: >> >>> On Tuesday 27 September 2005 15:56, Micah wrote: >>> >>>> The directory structure of fat32 is still the same as from dos. In >>>> order to create long filenames, Windows uses subsequent directory >>>> entries to store the extra filename characters. If a filename fits the >>>> 8.3 format, Windows (at least Win98) does not bother to create the >>>> extra >>>> entries for the long filename record. If there's no ong filename >>>> record, how can FreeBSD use the long filename? >>> >>> >>> >>> >>> >>> >>> The files in question are shown as having names like A.txt in >>> windows, ie mixed case. The Dos directory command always shows >>> completly uppercase names for the 8.3 names >>> >>> I have plenty of 8.3 files that dos DIR shows as having uppercase 8.3 >>> names *and* mixed/lower-case full names. So either dos/windows does >>> create the extra-filename for files with an 8.3 name format, or it >>> stores the mixed-case name in the legacy 8.3 field in it's case and >>> DIR converts to uppercase. >>> Either way around the case that is found by FreeBSD should be the >>> same as if it were reading a long-filename. >> >> >> >> I did some tests using Win98/qemu and Win2K/real hardware, and >> diskedit. This appears to be a real bug in how FreeBSD handles byte >> 12 of an 8.3 directory entry. It only shows up in 8.3 filenames >> created by Win2K (and presumably any NT based windows). Somehow (and >> I cannot find exact details, just passing references) NT stores >> filename capitalization of 8.3 names in byte 12 of an 8.3 directory >> entry, thereby eliminating the creation of an LFN (long filename) >> entry. FreeBSD doesn't interpret it correctly and displays file names >> in lowercase unless the original name was all uppercase letters. The >> solution: always use long filenames from an NT based Windows if you >> care about capitalization. At least until the bug is fixed in FreeBSD. >> > > exactly! > > i just did a simple test and created the following on win xp : > > w.TXT > X.TXT > Y.txt > z.txt > > and this is what freebsd displays: > > X.TXT > w.txt > y.txt > z.txt > > i think the case is clear. > > and what now? whom to report it to? > > regards, > > martin > I've found the troubled piece of code, just gotta figure out the best way to fix it. I'll come up with a patch and submit it as a PR I guess. (never done either, but I'm sure I'll figure it out. :) Later, Micah