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