Hi Stefano,

You've found a new bug ...

The foldcase mount option, as explained in the manpage mount_pcfs(1m), 
should return all filenames as uppercase only.

You find that it does not do that for the directory names, in fact it 
seems to do the reverse there.

But in any case, "foldcase" is not doing what you want. Even fixing the 
above will not give you the same behaviour as Linux/Windows.


That is historical. I don't know if I can somehow have the old ARC case 
for pcfs' "foldcase" mount option opened so that you can read up on the 
story - the behaviour is sort-of cast in stone there (unless someone 
requests _and_ implements a change).



Generically, FAT as a filesystem is _NOT_ case dependent. It does not, by 
definition, "allow" filename case as distinguisher.

What it shows and what it shows not is therefore, to a degree, irrelevant. 
The correct behaviour to deal with FAT filesystems would be to implement 
case-insensitive filename lookups, as per:

http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6417428

And:

http://www.opensolaris.org/os/community/arc/caselog/2007/244/

That'd give you the behaviour you get under Windows - the attempt to open 
"Doc.txt" will succeed if there's a "DOC.txt" or "DOC.TXT" or whatever 
combination of upper/lowercase.


I have to stress that anything else but that will not give you the 
semantics that you need to use FAT as "generic interchange filesystem", 
especially since you use it to build software on. And for archiving, 
you'll never quite get it to work correctly if you rely on filename case.

Strangely enough, if you _extract_ and archive with mixed-case short 
filenames on PCFS on Solaris, the case will be correct on 
Linux/Windows/Solaris. But that will _not_ be the situation if you extract 
on Linux/Windows. One could say what Solaris does works on all three of 
them while what Linux/Windows do does not. Pointing out bugs ... but then, 
technically the reason for that feature is a bug in Solaris, but it has so 
nice consequences that we preserve the behaviour ...


Sounds horribly incomprehensible ? Oh yes :(


As far as the timestamp issue goes - not much I can do there (right now).


FrankH.


On Thu, 10 Jan 2008, Stefano Spinucci wrote:

> Doing some tests with OpenSolaris and the "foldcase"/"nofoldcase" mount 
> option, I found that:
> * with the "nofoldcase" mount option (the default mount option) some short 
> dirs created on windows (and not on linux) are shown upcase, all others files 
> and dirs are shown correctly mixedcase
> * with the "foldcase" mount option the behavior is inverted, and some short 
> dirs created on windows are shown lowcase, all other files and dirs are shown 
> upcase
>
> maybe the upcase showing of short dirs created on windows in "nofoldcase" is 
> not a bug but a feature, but I don't understand why only Solaris/OpenSolaris 
> (and not Windows nor Linux) should display those dirs as upcase.
>
> furthermore, I guess the "foldcase" behavior is a bug, as you can see on the 
> attached list of three "ls -1R" on a test directory.
>
> "ls -1R" on Linux (ubuntu 7.10) with the standard mount option:
> testdir/linux:
> Dir.txt
> File.txt
> LongDirectory
> LongFileTxt.txt
> testdir/winxp:
> Dir.txt
> File.txt
> LongDirectory
> LongFileTxt.txt
>
> "ls -1R" on OpenSolaris (snv_75) with the standard mount option "nofoldcase":
> TESTDIR/linux:
> Dir.txt
> File.txt
> LongDirectory
> LongFileTxt.txt
> TESTDIR/WINXP:
> Dir.txt
> File.txt
> LongDirectory
> LongFileTxt.txt
>
> "ls -1R" on OpenSolaris (snv_75) with "foldcase" mount option :
> testdir/LINUX:
> DIR.TXT
> FILE.TXT
> LONGDIRECTORY
> LONGFILETXT.TXT
> testdir/winxp:
> DIR.TXT
> FILE.TXT
> LONGDIRECTORY
> LONGFILETXT.TXT
>
>
> PS
>
> I wrote 2 days ago to Prabahar Jeyar (the engineer who works on 6615883) 
> asking for confirmation that the subtle and potentially damaging date bug 'll 
> be fully resolved in snv_81, but I get no reply.
>
> Meanwhile, be careful considering a FAT32 filesystem useful to be 
> interoperable between OpenSolaris and Linux/Windows, because when copying a 
> file from a FAT32 disk the new file "access" and "modify" date is incremented 
> by 1 day, and when writing a file to a FAT32 disk also the "change" date is 
> incremented by 1 day.
>
> bye
>
> ---
> Stefano Spinucci
>
>>
>> Hi,
>>
>> already replied to the same posting from Stefano.
>> These are known:
>>
>> a) "case" is not a bug - see "foldcase" mount option.
>> b) The time difference is 6615883
>> c) The I/O error is very likely 6587983.
>>
>> No need to log new bugs.
>> Thanks,
>>
>> FrankH.
>>
>> On Sat, 5 Jan 2008, Stefano Spinucci wrote:
>>
>>> *** introductory notes ***
>>>
>>> message posted on opensolaris-discuss and
>> opensolaris-bugs
>>>
>>> the following bugs are tested with solaris,
>> opensolaris, linux and windows, on an manually
>> mounted internal FAT32 disk and an automatically
>> mounted external FAT32 key; solaris is "SunOS
>> solaris-devx 5.11 snv_70b i86pc i386 i86pc",
>> opensolaris is "SunOS opensolaris 5.11 snv_75 i86pc
>> i386 i86pc Solaris", linux is "Ubuntu 7.10", windows
>> is "Windows XP SP2".
>>>
>>>
>>> *** first bug: LAST MODIFICATION DATE/TIME AND CASE
>> WRONGLY SHOWN ON FILE READ ***
>>>
>>> description:
>>> - on solaris a lowcase file is shown as upcase +
>> the date is incremented of 1 day
>>> - on opensolaris a lowcase file is shown as upcase
>> + the date is incremented of 1 day and 1 hour
>>>
>>> listing the same directory on linux, windows,
>> solaris and opensolaris:
>>> ### linux: date ok, time ok, case ok
>>> total 12
>>> drwx------ 2 ste root 4096 2008-01-05 15:29 .
>>> drwx------ 7 ste root 4096 2008-01-05 16:38 ..
>>> -rwx------ 1 ste root 3399 2008-01-03 17:45 solaris
>>> ### windows: date ok, time ok, case ok
>>> 05/01/2008  11.29    <DIR>          .
>>> 05/01/2008  11.29    <DIR>          ..
>>> 03/01/2008  17.45             3.399 solaris
>>> ### solaris: date wrong, time ok, case wrong
>>> total 23
>>> drwxrwxrwx   1 ste      staff       4096 Jan  6
>> 14:45:50 2008 .
>>> drwxrwxrwx   1 ste      staff       4096 Jan  2
>> 00:00:00 1980 ..
>>> -rwxrwxrwx   1 ste      staff       3399 Jan  4
>> 17:45:36 2008 SOLARIS
>>> ### opensolaris: date wrong, time wrong, case wrong
>>> total 12
>>> drwxrwxrwx 1 ste staff 4096 Jan  6  2008 .
>>> drwxrwxrwx 1 ste staff 4096 Jan  5 16:11 ..
>>> -rwxrwxrwx 1 ste staff 3399 Jan  4 18:45 SOLARIS
>>>
>>>
>>> *** second bug: A FILE CREATED IN DAY 'N' HAS
>> MODIFY DAY 'N+1' AND IF COPIED WITH RSYNC HAS MODIFY
>> DATE 'N+2' ***
>>>
>>> description:
>>> - a file created today is written with date
>> tomorrow; copying the same file with "rsync --times"
>> some seconds after the creation the date of the
>> copied file is incremented of 2 days from today
>>>
>>> the script I used to test the bug with rsync:
>>> ### script to be executed on a FAT32 formatted
>> disk.
>>> ### the sleep is needed to let the bug manifest
>> himself
>>> ###
>>> ### note that the current date is 2007-1-5, the
>> file is created with date
>>> ### 2007-1-6 and rsync copied with date 2007-1-7
>>> # date
>>> Sat Jan  5 15:21:31 CET 2008
>>> [ ! -d testdir ] && mkdir testdir
>>> [ ! -d testdir.bak ] && mkdir testdir.bak
>>> # echo xyz > testdir/testfile
>>> # stat testdir/testfile
>>>  File: `testdir/testfile'
>>>  Size: 4               Blocks: 1          IO Block:
>> 4096   regular file
>>> Device: 1981010h/26742800d      Inode: 1711135027
>>  Links: 1
>> Access: (0777/-rwxrwxrwx)  Uid: (  101/     ste)
>>    Gid: (   10/   staff)
>> ccess: 2008-01-06 15:21:30.000000000 +0100
>>> Modify: 2008-01-06 15:21:30.000000000 +0100
>>> Change: 2008-01-06 15:21:30.000000000 +0100
>>> # sleep 2
>>> # rsync --times testdir/* testdir.bak/
>>> # stat testdir.bak/testfile
>>>  File: `testdir.bak/testfile'
>>>  Size: 4               Blocks: 1          IO Block:
>> 4096   regular file
>>> Device: 1981010h/26742800d      Inode: 1711135157
>>  Links: 1
>> Access: (0777/-rwxrwxrwx)  Uid: (  101/     ste)
>>    Gid: (   10/   staff)
>> ccess: 2008-01-06 01:00:00.000000000 +0100
>>> Modify: 2008-01-07 15:21:30.000000000 +0100
>>> Change: 2008-01-07 15:21:30.000000000 +0100
>>>
>>>
>>> *** third bug: I/O ERROR ON A GOOD FILE ***
>>>
>>> a file, correctly read (with md5sum) by linux and
>> windows shows the following error on solaris and
>> opensolaris:
>>> # md5sum
>> /media/lap0-iop/mydocuments/it.repo/office/ooo/docs/02
>> 00WG-WriterGuide.pdf
>>> md5sum:
>> /media/lap0-iop/mydocuments/it.repo/office/ooo/docs/02
>> 00WG-WriterGuide.pdf: I/O error
>>>
>>>
>>> *** final notes ***
>>>
>>> I'm a former fulltime linux user, willing to use
>> linux as a desktop and solaris as my file server.
>>>
>>> Please let me know if I can do something to help
>> further with those bugs...
>>>
>>> bye
>>>
>>> ---
>>> Stefano Spinucci
>>>
>>>
>>> This message posted from opensolaris.org
>>> _______________________________________________
>>> opensolaris-bugs mailing list
>>> [EMAIL PROTECTED]
>>>
>> _______________________________________________
>> opensolaris-bugs mailing list
>> [EMAIL PROTECTED]
>
>
> This message posted from opensolaris.org
> _______________________________________________
> opensolaris-discuss mailing list
> [email protected]
>
_______________________________________________
opensolaris-discuss mailing list
[email protected]

Reply via email to