Hi,
~
I just noticed a bug the while coding, that made me spend quite a big
of time eyeballing, cleaning up and mentally remapping my code and I
believe to have reduced to a bug caused by some nasty VFAT + Linux/
Knoppix impedance
~
1._ I am using Linux/Knoppix 5.1.1 based on the 2.6.19 Linux kernel
~
sh-3.1# su -
root@Knoppix:~# uname -r
2.6.19
~
2._ which I booted with the cheatcode
~
"knoppix acpi=off noapic testcd init 2"
~
because the Linux/knoppix version 5.1.1 based on the 2.6.19 fills the
dmesg output with errors:
CPU0: 01(01)
APIC error on CPU0: 01(01) (<- lots of these)
spurious APIC interrupt on CPU#0, should never happen. (also, but not
as many as the previous one)
~
3._ I dumped the output of dmesg
~
root!tty1:/# dmesg > 00_dmesg_acpi_eq_off_noapic_testcd_init_2.txt
~
4._ I tried mounting the vfat fs /dev/hdb6 using
~
root!tty1:/# mount /media/hdb6
~
but then while moving/copying files to directories in this fs I would
get
~
root!tty1:/# mv *.txt /media/hdb6/bugs
root!tty1:/# mv failed to preserve ownership for '/media/hdb6/bugs/
00_dmesg_acpi_eq_off_noapic_testcd_init_2.txt' Operation not permitted
~
mounting the fs using the stanza
~
root!tty1:/# mount -t vfat /dev/hdb6 /media/hdb6
~
appears to rid you of these ownership transfer losses
~
5._ I then started X via
~
root!tty1:/# startx
~
6._ opened a shell went to a folder in the vfat fs and created files
with the same name but with the difference of a lower and upper case
extension
~
root@Knoppix:/media/hdb6/prjx/bugs# echo "test lower case extension" >
test.txt
root@Knoppix:/media/hdb6/prjx/bugs# echo "test upper case extension" >
test.TXT
~
7._ but even if the file with the upper case version is there (which
you only see by invoking it with its full name)
~
root@Knoppix:/media/hdb6/prjx/bugs# ls -l test.TXT
-rwxr-xr-x 1 root root 26 May 7 06:40 test.TXT
~
Linux is not 'seeing it' if you wild card expressions or just list
all files
~
root@Knoppix:/media/hdb6/prjx/bugs# ls -l *.TXT
ls: *.TXT: No such file or directory
root@Knoppix:/media/hdb6/prjx/bugs# ls -l
total 176
-rwxr-xr-x 1 root root 12889 May 7 05:59
00_dmesg_acpi_eq_off_noapic_testcd_init_2.txt
-rwxr-xr-x 1 root root 12889 May 7 05:59 02_dmesg_mount_-
t_vfat_dev_hdb6_media_hdb6.txt
-rwxr-xr-x 1 root root 29501 May 7 05:05
1st_trial_00_dmesg_after_boot.txt
-rwxr-xr-x 1 root root 650 May 7 05:12
1st_trial_04_fdisk_dev_hdb.txt
-rwxr-xr-x 1 root root 1542 May 7 06:39 LinuxVFatBug00.txt
-rwxr-xr-x 1 root root 1342 May 7 06:35 LinuxVFatBug00.txt~
-rwxr-xr-x 1 root root 3687 May 7 05:59 cp--help.txt
-rwxr-xr-x 1 root root 208 May 7 06:02 md5sum00.txt
-rwxr-xr-x 1 root root 526 May 7 06:02 md5sum02.txt
-rwxr-xr-x 1 root root 26 May 7 06:40 test.txt
~
root@Knoppix:/media/hdb6/prjx/bugs# ls -l *.txt
-rwxr-xr-x 1 root root 12889 May 7 05:59
00_dmesg_acpi_eq_off_noapic_testcd_init_2.txt
-rwxr-xr-x 1 root root 12889 May 7 05:59 02_dmesg_mount_-
t_vfat_dev_hdb6_media_hdb6.txt
-rwxr-xr-x 1 root root 29501 May 7 05:05
1st_trial_00_dmesg_after_boot.txt
-rwxr-xr-x 1 root root 650 May 7 05:12
1st_trial_04_fdisk_dev_hdb.txt
-rwxr-xr-x 1 root root 1542 May 7 06:39 LinuxVFatBug00.txt
-rwxr-xr-x 1 root root 3687 May 7 05:59 cp--help.txt
-rwxr-xr-x 1 root root 208 May 7 06:02 md5sum00.txt
-rwxr-xr-x 1 root root 526 May 7 06:02 md5sum02.txt
-rwxr-xr-x 1 root root 26 May 7 06:40 test.txt
~
root@Knoppix:/media/hdb6/prjx/bugs# md5sum *.txt
4d0a8122383095005be55c8daed3aac9
00_dmesg_acpi_eq_off_noapic_testcd_init_2.txt
4d0a8122383095005be55c8daed3aac9 02_dmesg_mount_-
t_vfat_dev_hdb6_media_hdb6.txt
0291b2e145614198136599426f012e42 1st_trial_00_dmesg_after_boot.txt
3120b0f6172325eb4fad5c502b390b7e 1st_trial_04_fdisk_dev_hdb.txt
8380bad18b88152267686976bcbf5213 LinuxVFatBug00.txt
f7dd8b7cc5d6115be6b09186106862d1 cp--help.txt
7b9be97a510ba89b8d06cdff28e02ed8 md5sum00.txt
ec0a023c6a8c31c47232640a16f27ea4 md5sum02.txt
76744305c32618225193b5556c8b091e test.txt
~
root@Knoppix:/media/hdb6/prjx/bugs# md5sum *.TXT
md5sum: *.TXT: No such file or directory
~
Obviously this impedance regarding file names/extensions would
transpire to the JVM, since it works on top of the OS services +
utilities and the OS + VFAT FS
~
However what I don't quite get is why a class implementing
http://java.sun.com/javase/6/docs/api/index.html such as:
~
// __
class DirFilter implements FilenameFilter{
public boolean accept(File FlDir, String aFl){
boolean IsAccept = (FlDir.isDirectory());
if(IsAccept){
File Fl = new File(FlDir, aFl);
IsAccept = Fl.exists();
if(IsAccept){
aFl = Fl.getAbsolutePath();
if(!IsAll){
IsAccept = false;
for(int i = 0; (i < aExtAr.length) && !IsAccept; ++i){
IsAccept = aFl.endsWith(aExtAr[i]);
}
}// (!IsAll)
}// (Fl.exists())
}// (FlDir.isDirectory())
// __
return(IsAccept);
}
}
~
would not pick all files with both extensions
~
when you go
~
DirFilter FlsFltr = new DirFilter();
File[] XFls = FlDir.listFiles(FlsFltr);
~
even if it detected in its accept implemented method both extensions
just fine!!!
~
I degugged and eyeballed it carefully, but you should check it out
yourself
~
I think there is impedance among the three parts:
~
* the OS Linux honoring this MS FAT32 requirements file system
filenames in which you get filenames stored in a case-sensitive
manner, but
filenames being treated as if they were case-insensitive. So this
might be creating this file name "ghosts" problem
* the JVM not knowing what to do with this conflict
~
I code mostly Java and I need to use FAT32 to keep the files in my
external drive easily accessible when I am working in a Linux,
Solaris, WIndows or MacOS box, but this filename thing is creating
problems
~
How do people keep their data portable regarding file system names?
Just using all lower or uppercase?
~
Thanks
lbrtchx

lbrtchx********.com wrote:
> * the OS Linux honoring this MS FAT32 requirements file system
> filenames in which you get filenames stored in a case-sensitive
> manner, but
> filenames being treated as if they were case-insensitive. So this
> might be creating this file name "ghosts" problem
> * the JVM not knowing what to do with this conflict
> ~
> I code mostly Java and I need to use FAT32 to keep the files in my
> external drive easily accessible when I am working in a Linux,
> Solaris, WIndows or MacOS box, but this filename thing is creating
> problems
> ~
> How do people keep their data portable regarding file system names?
> Just using all lower or uppercase?

I use Fedora Core 6 and it has no trouble whatsoever listing upper- vs.
lower-case names on s FAT-formatted drive:

$ touch temp.T
$ ls *.T
temp.T
$ ls *.t
ls: *.t: No such file or directory
$

This from a cwd on a FAT-formatted Windows drive.

--
Lew

> ... no trouble whatsoever listing upper- vs. lower-case
Not quite what I took the time to explain. Anyway, why don't you also
~
$ touch temp.t
~
and then test what I said?
~
Also, which kernel does this version of Fedora use?
~
lbrtchx

<lbrtchx********.com> wrote in message
news:1178536824.157414.92110@p77g2000hsh.googlegro ups.com...
>
> because the Linux/knoppix version 5.1.1 based on the 2.6.19 fills the
> dmesg output with errors:

Can't comment on that ...

> 4._ I tried mounting the vfat fs /dev/hdb6 using
> ~
> root!tty1:/# mount /media/hdb6

Which mounts the drive according to the parameters set up in fstab, which is
normally in the /etc directory. It might have been useful to let us see the
config line from that file which mounts the drive ...

> root!tty1:/# mount -t vfat /dev/hdb6 /media/hdb6
> ~
> appears to rid you of these ownership transfer losses

The difference in behaviour is almost certainly to be found in the
difference between the manually given command and what is in the fstab file.

The FAT32 filesystem holds no information about file ownership at all. This
can be seen most clearly when a FAT32 drive is mounted in an Windows NTFS
system. In such a system, if you right-click any NTFS drive or any
directory or file thereon and choose Properties, there is a Security tab,
but if you do the same with a FAT32 drive, there isn't.

Thus any 'file ownership' on a FAT32 drive that you see in Linux is virtual,
it is being faked by Linux, and IIRC exactly how it does so can be altered
by mount parameters.

Also, as you are obviously aware, FAT32 ignores differences in case, and
again exactly how it does this can be determined by mount parameters.

I suggest you read the manual for mount,
http://www.linuxcommand.org/man_pages/mount8.html, with particular reference
to the sections 'Options' and 'Mount options for vfat', for example those
that deal with read only/read write and security such as ...
users Allow every user to mount and unmount the file system.
.... and those that deal with filename translation such as ...
posix Allow two files with names that only differ in case.

These sorts of switches will almost certainly explain the differences in
ownership that you are encountering with the different ways of mounting the
drive, and you should be able to configure the default mounting in fstab in
such a way as to get the case behaviour you expect.

> Obviously this impedance regarding file names/extensions would
> transpire to the JVM, since it works on top of the OS services +
> utilities and the OS + VFAT FS
> ~
> However what I don't quite get is why a class implementing
> http://java.sun.com/javase/6/docs/api/index.html such as:

Yes, that is almost certainly why your Java appears to be failing, it is
merely passing on the incorrect information being given to it by the VFAT
FS. However, if you are worried about your Java (mine's getting a little
rusty now and I regret I can't be arsed to examine it closely), I suggest
you check its behaviour on a Linux Ext2/3 drive. If it does what is
expected there, but not on the VFAT, then VFAT is surely the problem?

> How do people keep their data portable regarding file system names?
> Just using all lower or uppercase?

Because of issues such as you've highlighted, I tend to create a tar on the
Linux drive and then just copy the tar off to FAT32 or wherever. That way,
all the Linux ext2/3-specific FS information, such as ownership/symbolic
links, is preserved.

On 7 May 2007 04:20:24 -0700, lbrtchx********.com
<lbrtchx********.com> wrote:
>
>
> Hi,
> ~
> I just noticed a bug the while coding, that made me spend quite a big
> of time eyeballing, cleaning up and mentally remapping my code and I
> believe to have reduced to a bug caused by some nasty VFAT + Linux/
> Knoppix impedance
> ~
> 1._ I am using Linux/Knoppix 5.1.1 based on the 2.6.19 Linux kernel
> ~
> sh-3.1# su -
> root@Knoppix:~# uname -r
> 2.6.19
> ~
> 2._ which I booted with the cheatcode
> ~
> "knoppix acpi=off noapic testcd init 2"
> ~
> because the Linux/knoppix version 5.1.1 based on the 2.6.19 fills the
> dmesg output with errors:
> CPU0: 01(01)
> APIC error on CPU0: 01(01) (<- lots of these)
> spurious APIC interrupt on CPU#0, should never happen. (also, but not
> as many as the previous one)
> ~
This is a hardware issue, not related to the peculiarities of the vfat
file system.

> 3._ I dumped the output of dmesg
> ~
> root!tty1:/# dmesg > 00_dmesg_acpi_eq_off_noapic_testcd_init_2.txt
> ~
> 4._ I tried mounting the vfat fs /dev/hdb6 using
> ~
> root!tty1:/# mount /media/hdb6
> ~
> but then while moving/copying files to directories in this fs I would
> get
> ~
> root!tty1:/# mv *.txt /media/hdb6/bugs
> root!tty1:/# mv failed to preserve ownership for '/media/hdb6/bugs/
> 00_dmesg_acpi_eq_off_noapic_testcd_init_2.txt' Operation not permitted
> ~
> mounting the fs using the stanza
> ~
> root!tty1:/# mount -t vfat /dev/hdb6 /media/hdb6
> ~
> appears to rid you of these ownership transfer losses
> ~
When you mount a vfat filesystem, all files get the owner and group of
the user who mounted it, unless a UID and/or GID are specified in
/etc/fstab, or in the command line when root gives the command and
names both the device and mount point.

> 5._ I then started X via
> ~
> root!tty1:/# startx
> ~
> 6._ opened a shell went to a folder in the vfat fs and created files
> with the same name but with the difference of a lower and upper case
> extension
> ~
> root@Knoppix:/media/hdb6/prjx/bugs# echo "test lower case extension" >
> test.txt
> root@Knoppix:/media/hdb6/prjx/bugs# echo "test upper case extension" >
> test.TXT
> ~
> 7._ but even if the file with the upper case version is there (which
> you only see by invoking it with its full name)
> ~
> root@Knoppix:/media/hdb6/prjx/bugs# ls -l test.TXT
> -rwxr-xr-x 1 root root 26 May 7 06:40 test.TXT
> ~
> Linux is not 'seeing it' if you wild card expressions or just list
> all files
> ~
> root@Knoppix:/media/hdb6/prjx/bugs# ls -l *.TXT
> ls: *.TXT: No such file or directory

Did you check the contents? cat test.txt test.TXT
I think you will find they are the same file.

According to the mount man page, if you mount with the options "posix"
and "shortname=mixed", it should allow files whose names differ only in
case, but I wasn't able to create such files.

> How do people keep their data portable regarding file system names?
> Just using all lower or uppercase?

Don't use filenames that differ only in case.


--
<Tarzan> hey did you fall off your pirch or something?
<knghtbrd> me? heh.

lbrtchx********.com wrote:> ~
> I code mostly Java and I need to use FAT32 to keep the files in my
> external drive easily accessible when I am working in a Linux,
> Solaris, WIndows or MacOS box, but this filename thing is creating
> problems

if you look at the fstab table you will see that knoppix keeps on writing a
new fstab table. I had this when i used knoppix 5.1.1. You have to do some
thing to the kernel to stop this. go here:

http://www.knoppix.net/forum/index.p...c21297359f262d

they will be in a better place to help you