# VFAT comportamento anomalo in fase di copia [RISOLTO]

## Peach

UPDATE: qui la soluzione al problema.

Occhio, perché questo che vi sto per raccontare ha dell'incredibile ai miei occhi.

Tenete presente che SO che vfat è caseINsensitive (e che è pure un FS di merda, ma questa è un'altra storia).

Ora ho una dir nella home dell'utente su un fs reiser montato con opzioni noatime e rw.

Voglio copiare questo file a scopi di backup su un disco iomega esterno (vfat) montato con le opzioni rw,sync,uid=1000,gid=100,codepage=850,iocharset=iso8859-15.

e fin qui...

ora fate attenzione alla maggìa

```
# pwd

/home/b/dir

# ls -l

-rwxr-xr-x 1 b users 676389 Aug 10  2004 DSCN5967(1).JPG

-rwxr-xr-x 1 b users 710090 Aug 10  2004 DSCN5968(1).JPG

-rwxr-xr-x 1 b users 732903 Aug 10  2004 DSCN5981.JPG.rem.2006-10-27-1543

-rwxr-xr-x 1 b users 622595 Aug 10  2004 DSCN5982.JPG.rem.2006-10-27-1543

# cp -v DSCN5967\(1\).JPG DSCN5968\(1\).JPG DSCN5981.JPG.rem.2006-10-27-1543 DSCN5982.JPG.rem.2006-10-27-1543 /mnt/iomega/dir/

`DSCN5967(1).JPG' -> `/mnt/iomega/dir/DSCN5967(1).JPG'

`DSCN5968(1).JPG' -> `/mnt/iomega/dir/DSCN5968(1).JPG'

`DSCN5981.JPG.rem.2006-10-27-1543' -> `/mnt/iomega/dir/DSCN5981.JPG.rem.2006-10-27-1543'

`DSCN5982.JPG.rem.2006-10-27-1543' -> `/mnt/iomega/dir/DSCN5982.JPG.rem.2006-10-27-1543'

# ls -l /mnt/iomega/dir/

total 2784

-rwxr-xr-x 1 b users 676389 Oct 27 16:55 DSCN5967(1).JPG

-rwxr-xr-x 1 b users 710090 Oct 27 16:55 DSCN5968(1).JPG

-rwxr-xr-x 1 b users 732903 Oct 27 16:55 dscn5981.jpg.rem.2006-10-27-1543

-rwxr-xr-x 1 b users 622595 Oct 27 16:55 dscn5982.jpg.rem.2006-10-27-1543
```

 :Question:   :Confused:  com'è sta cosa... i file sono in minuscolo!!!!!!!!! ma solo due!

ora prestate ancora attenzione:

```
# pwd

/home/b/dir

# cp -v DSCN5981.JPG.rem.2006-10-27-1543 DSCN5981.JPG.rem.9999-99-99-9999

`DSCN5981.JPG.rem.2006-10-27-1543' -> `DSCN5981.JPG.rem.9999-99-99-9999'

# cp -v DSCN5981.JPG.rem.9999-99-99-9999 /mnt/iomega/dir/

`DSCN5981.JPG.rem.9999-99-99-9999' -> `/mnt/iomega/dir/DSCN5981.JPG.rem.9999-99-99-9999'

# ls -l /mnt/iomega/dir/

total 2784

-rwxr-xr-x 1 b users 676389 Oct 27 16:55 DSCN5967(1).JPG

-rwxr-xr-x 1 b users 710090 Oct 27 16:55 DSCN5968(1).JPG

-rwxr-xr-x 1 b users 732903 Oct 27 17:01 DSCN5981.JPG.rem.9999-99-99-9999

-rwxr-xr-x 1 b users 732903 Oct 27 16:55 dscn5981.jpg.rem.2006-10-27-1543

-rwxr-xr-x 1 b users 622595 Oct 27 16:55 dscn5982.jpg.rem.2006-10-27-1543
```

spettacolare, nevvero?

a voi la parola. Se servono maggiori informazioni sono a vostra disposizione. Vorrei venire a capo di questo problema.

----------

## earcar

Secondo me la risposta ce l'hai nella domanda...  :Very Happy: 

 *Peach wrote:*   

> Tenete presente che SO che vfat è caseINsensitive

 

Pero' effettivamente sarebbe interessante capire perche' si comporta in maniera diversa con alcuni file...  :Rolling Eyes: 

Passo e chiudo a chi ne sa di piu'

----------

## Peach

si. Tra l'altro Flameeyes mi fa notare che quando crei da *nix il file, si "fissa" il case, ma non trovo spiegazione per questo comportamento. Visto che i file sono condivisi via samba, anche se è Windows che li crea, qualcuno sotto linux si incaricherà di metterli fisicamente su disco e il disco è reiser. Quindi quando li sposto sotto vfat non c'è ragione che "il case non sia fissato", non so se mi spiego...

----------

## cloc3

curioso.

ma è un falso problema: i nomi dei file non sono case insensitive, ma quelli dei nodi sì.

guarda questo esperimento, in cui la cartella prova è montata in loop su un file system vfat:

```

s939 ~ # pwd

/root

s939 ~ # mount|grep vfat

/dev/loop/0 on /root/prova type vfat (rw)

s939 ~ # touch DSCN5967\(1\).JPG

s939 ~ # mv DSCN5967\(1\).JPG prova/

s939 ~ # ls prova/

DSCN5967(1).JPG

s939 ~ # touch DsCN5967\(1\).JPG

s939 ~ # mv DsCN5967\(1\).JPG prova/

s939 ~ # ls prova/

DsCN5967(1).JPG

```

il file DSCN5967(1).JPG, creato nella root, viene spostato nel file system vfat, dove, rimane visualizzato come tale, senza conversione.

muovendo in prova il file DsCN5967(1).JPG, tuttavia, si ottiene, anziché la creazione di un nuovo nodo nel filesystem, la sovrascrittura del precedente documento.

Ma che bel trucchetto per perdere dati   :Laughing:  !!!

cosa dicevi, oltre al fatto che vfat è un file system case insensitive?

----------

## Peach

 *cloc3 wrote:*   

> ma è un falso problema: i nomi dei file non sono case insensitive, ma quelli dei nodi sì.

 

si, praticamente non ammette due file con lo stesso nome, questa è la case insensitiveness di vfat.

 *cloc3 wrote:*   

> guarda questo esperimento, in cui la cartella prova è montata in loop su un file system vfat:
> 
> SNIP

 

In ogni caso, come anche fai vedere tu, un carattere maiuscolo è diverso dallo stesso in minuscolo (dal punto di vista ASCII) anche in vfat. Se cambia il case qualcosa sinceramente non va, o almeno non trovo nessuna motivazione logica perché ciò avvenga.

----------

## cloc3

 *Peach wrote:*   

> o almeno non trovo nessuna motivazione logica perché ciò avvenga.

 

la logica è che, semplicemente, non c'è una logica.

una vfat - lo dice il nome - è una banale tabella di allocazione.

numero nodo - nome nodo

numero nodo - nome nodo

...

i nomi nodo sono stringhe. che tu le riempia di caratteri minuscoli o maiuscoli non importa a nessuno.

e saranno lette come stanno.

dopo, ai tuoi backup scapperà da ridere.

----------

## cerri

Prova un paio di test:

```
# strace -fF -o /root/strace.log cp -v DSCN5967\(1\).JPG DSCN5968\(1\).JPG DSCN5981.JPG.rem.2006-10-27-1543 DSCN5982.JPG.rem.2006-10-27-1543 /mnt/iomega/dir/

# tar cvf - * | tar xf - -C /mnt/iomega/dir/
```

Ovviamente devi postare il file /root/strace.log.

Tra l'altro io ho fatto un paio di prove:

```
root@1[peach]# touch DSCN5981.JPG.rem.2006-10-27-1543

root@1[peach]# touch DSCN5982.JPG.rem.2006-10-27-1543

root@1[peach]# touch "DSCN5967(1).JPG"

root@1[peach]# touch "DSCN5968(1).JPG"

root@1[peach]# ls -la

totale 0

drwxr-xr-x 2 root root 120 2006-10-29 13:44 .

drwxrwxrwt 9 root root 180 2006-10-29 13:43 ..

-rwxr-xr-x 1 root root   0 2006-10-29 13:44 DSCN5967(1).JPG

-rwxr-xr-x 1 root root   0 2006-10-29 13:44 DSCN5968(1).JPG

-rwxr-xr-x 1 root root   0 2006-10-29 13:44 DSCN5981.JPG.rem.2006-10-27-1543

-rwxr-xr-x 1 root root   0 2006-10-29 13:44 DSCN5982.JPG.rem.2006-10-27-1543

root@1[peach]# cp -v DSCN5967\(1\).JPG DSCN5968\(1\).JPG DSCN5981.JPG.rem.2006-10-27-1543 DSCN5982.JPG.rem.2006-10-27-1543 /mnt/appoggio/peach

`DSCN5967(1).JPG' -> `/mnt/appoggio/peach/DSCN5967(1).JPG'

`DSCN5968(1).JPG' -> `/mnt/appoggio/peach/DSCN5968(1).JPG'

`DSCN5981.JPG.rem.2006-10-27-1543' -> `/mnt/appoggio/peach/DSCN5981.JPG.rem.2006-10-27-1543'

`DSCN5982.JPG.rem.2006-10-27-1543' -> `/mnt/appoggio/peach/DSCN5982.JPG.rem.2006-10-27-1543'

root@1[peach]# ls -la /mnt/appoggio/peach

totale 32

drwxr-xr-x 2 root root 16384 2006-10-29 13:50 .

drwxr-xr-x 3 root root 16384 2006-10-29 13:45 ..

-rwxr-xr-x 1 root root     0 2006-10-29 13:50 DSCN5967(1).JPG

-rwxr-xr-x 1 root root     0 2006-10-29 13:50 DSCN5968(1).JPG

-rwxr-xr-x 1 root root     0 2006-10-29 13:50 DSCN5981.JPG.rem.2006-10-27-1543

-rwxr-xr-x 1 root root     0 2006-10-29 13:50 DSCN5982.JPG.rem.2006-10-27-1543

root@1[peach]# dd if=/dev/zero of=./reiser bs=1024k count=50

50+0 records in

50+0 records out

52428800 bytes (52 MB) copied, 0,184898 seconds, 284 MB/s

root@1[peach]# mkreiserfs ./reiser -f

mkreiserfs 3.6.19 (2003 www.namesys.com)

A pair of credits:

Hans Reiser was the project initiator,  source of all funding for the first 5.5

years. He is the architect and official maintainer.

Edward Shushkin wrote the encryption and compression  file plugins,  and the V3

journal relocation code.

./reiser is not a block special device

Continue (y/n):y

Guessing about desired format.. Kernel 2.6.17 is running.

Format 3.6 with standard journal

Count of blocks on the device: 12800

Number of blocks consumed by mkreiserfs formatting process: 8212

Blocksize: 4096

Hash function used to sort names: "r5"

Journal Size 8193 blocks (first block 18)

Journal Max transaction length 1024

inode generation number: 0

UUID: 99541b7d-91fc-47df-abb6-8dfcfdf46ed4

Initializing journal - 0%....20%....40%....60%....80%....100%

Syncing..ok

Tell your friends to use a kernel based on 2.4.18 or later, and especially not a

kernel based on 2.4.9, when you use reiserFS. Have fun.

ReiserFS is successfully created on ./reiser.

root@1[peach]# mount -o loop ./reiser peachreiser/

root@1[peach]# cd peachreiser

root@1[peachreiser]# rm /mnt/appoggio/peach/DS*

root@1[peachreiser]# cp ../DS* .

root@2[peachreiser]# cp -v DSCN5967\(1\).JPG DSCN5968\(1\).JPG DSCN5981.JPG.rem.2006-10-27-1543 DSCN5982.JPG.rem.2006-10-27-1543 /mnt/appoggio/peach

`DSCN5967(1).JPG' -> `/mnt/appoggio/peach/DSCN5967(1).JPG'

`DSCN5968(1).JPG' -> `/mnt/appoggio/peach/DSCN5968(1).JPG'

`DSCN5981.JPG.rem.2006-10-27-1543' -> `/mnt/appoggio/peach/DSCN5981.JPG.rem.2006-10-27-1543'

`DSCN5982.JPG.rem.2006-10-27-1543' -> `/mnt/appoggio/peach/DSCN5982.JPG.rem.2006-10-27-1543'

root@2[peachreiser]# ls -la /mnt/appoggio/peach

totale 32

drwxr-xr-x 2 root root 16384 2006-10-29 14:03 .

drwxr-xr-x 3 root root 16384 2006-10-29 13:45 ..

-rwxr-xr-x 1 root root     0 2006-10-29 14:03 DSCN5967(1).JPG

-rwxr-xr-x 1 root root     0 2006-10-29 14:03 DSCN5968(1).JPG

-rwxr-xr-x 1 root root     0 2006-10-29 14:03 DSCN5981.JPG.rem.2006-10-27-1543

-rwxr-xr-x 1 root root     0 2006-10-29 14:03 DSCN5982.JPG.rem.2006-10-27-1543
```

Però la cosa che non mi avevi detto al telefono è che si tratta di uno iomega... Non vorrei che qualche driver iomega sia fallato.

Come lo vedi? Semplice usb-storage?

Puoi provare a fare la stessa cosa con una chiavetta usb?

O un file come ho fatto io ma vfat?

Ciao boss

----------

## Peach

Tengo a precisare che speravo che l'opzione di vfat 

```
strict=s
```

 potesse risolvere i miei problemi, ma così non è stato.

 *cerri wrote:*   

> Prova un paio di test:

 

questo è l'output di strace:

```
19261 execve("/usr/bin/cp", ["cp", "-v", "DSCN5980.JPG", "/mnt/iomega/dir"...], [/* 26 vars */]) = 0

19261 brk(0)                            = 0x8066000

19261 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fd4000

19261 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)

19261 open("/etc/ld.so.cache", O_RDONLY) = 3

19261 fstat64(3, {st_mode=S_IFREG|0644, st_size=20562, ...}) = 0

19261 mmap2(NULL, 20562, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fce000

19261 close(3)                          = 0

19261 open("/lib/libacl.so.1", O_RDONLY) = 3

19261 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\23"..., 512) = 512

19261 fstat64(3, {st_mode=S_IFREG|0755, st_size=26740, ...}) = 0

19261 mmap2(NULL, 26316, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7fc7000

19261 mmap2(0xb7fcd000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x5) = 0xb7fcd000

19261 close(3)                          = 0

19261 open("/lib/libattr.so.1", O_RDONLY) = 3

19261 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\f\0"..., 512) = 512

19261 fstat64(3, {st_mode=S_IFREG|0755, st_size=13728, ...}) = 0

19261 mmap2(NULL, 16076, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7fc3000

19261 mmap2(0xb7fc6000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2) = 0xb7fc6000

19261 close(3)                          = 0

19261 open("/lib/libc.so.6", O_RDONLY)  = 3

19261 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320Y\1"..., 512) = 512

19261 fstat64(3, {st_mode=S_IFREG|0755, st_size=1234588, ...}) = 0

19261 mmap2(NULL, 1173116, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7ea4000

19261 mmap2(0xb7fbc000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x117) = 0xb7fbc000

19261 mmap2(0xb7fc0000, 9852, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7fc0000

19261 close(3)                          = 0

19261 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ea3000

19261 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7ea38c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present

:0, useable:1}) = 0

19261 mprotect(0xb7fbc000, 8192, PROT_READ) = 0

19261 mprotect(0xb7fef000, 4096, PROT_READ) = 0

19261 munmap(0xb7fce000, 20562)         = 0

19261 brk(0)                            = 0x8066000

19261 brk(0x8087000)                    = 0x8087000

19261 geteuid32()                       = 0

19261 stat64("/mnt/iomega/dir", {st_mode=S_IFDIR|0755, st_size=32768, ...}) = 0

19261 stat64("DSCN5980.JPG", {st_mode=S_IFREG|0755, st_size=699770, ...}) = 0

19261 stat64("/mnt/iomega/dir/DSCN5980.JPG", 0xbfbeba30) = -1 ENOENT (No such file or directory)

19261 fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0

19261 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fd3000

19261 write(1, "`DSCN5980.JPG\' -> `/mnt/iomega/d"..., 73) = 73

19261 open("DSCN5980.JPG", O_RDONLY|O_LARGEFILE) = 3

19261 fstat64(3, {st_mode=S_IFREG|0755, st_size=699770, ...}) = 0

19261 open("/mnt/iomega/dir/DSCN5980.JPG", O_WRONLY|O_CREAT|O_LARGEFILE, 0100755) = 5

19261 fstat64(5, {st_mode=S_IFREG|0755, st_size=0, ...}) = 0

19261 fstat64(3, {st_mode=S_IFREG|0755, st_size=699770, ...}) = 0

19261 time(NULL)                        = 1162218621

19261 read(3, "\377\330\377\3418EExif\0\0II*\0\10\0\0\0\v\0\16\1\2\0\v"..., 32768) = 32768

19261 write(5, "\377\330\377\3418EExif\0\0II*\0\10\0\0\0\v\0\16\1\2\0\v"..., 32768) = 32768

19261 time(NULL)                        = 1162218621

19261 read(3, "w`8\317\7\270\250k\2606\371\232\260>K\1\316;\343\265*\221"..., 32768) = 32768

19261 write(5, "w`8\317\7\270\250k\2606\371\232\260>K\1\316;\343\265*\221"..., 32768) = 32768

19261 time(NULL)                        = 1162218621

19261 read(3, "\200 \333\327\2414\3577)\353\357J\300\245a\f\231\7\333"..., 32768) = 32768

19261 write(5, "\200 \333\327\2414\3577)\353\357J\300\245a\f\231\7\333"..., 32768) = 32768

19261 time(NULL)                        = 1162218621

19261 read(3, ":R4%[n9a\300\36\236\364%\313\271\232\214\357`0\5\4\266"..., 32768) = 32768

19261 write(5, ":R4%[n9a\300\36\236\364%\313\271\232\214\357`0\5\4\266"..., 32768) = 32768

19261 time(NULL)                        = 1162218621

19261 read(3, "\344\4\201\3623\f\212\211\240\275[\243\7\332\30J\303!]"..., 32768) = 32768

19261 write(5, "\344\4\201\3623\f\212\211\240\275[\243\7\332\30J\303!]"..., 32768) = 32768

19261 time(NULL)                        = 1162218621

19261 read(3, "NG\251\246\t\362\200|\251\364\315\f\333@\376b\204+\365"..., 32768) = 32768

19261 write(5, "NG\251\246\t\362\200|\251\364\315\f\333@\376b\204+\365"..., 32768) = 32768

19261 time(NULL)                        = 1162218621

19261 read(3, "\315c}\205$3\34\237\304rk\207\370\230\245o\3741\300\31"..., 32768) = 32768

19261 write(5, "\315c}\205$3\34\237\304rk\207\370\230\245o\3741\300\31"..., 32768) = 32768

19261 time(NULL)                        = 1162218621

19261 read(3, "\3\"\224z\234\362JR\320\266\340\214\340\257\35\230T\f\1"..., 32768) = 32768

19261 write(5, "\3\"\224z\234\362JR\320\266\340\214\340\257\35\230T\f\1"..., 32768) = 32768

19261 time(NULL)                        = 1162218621

19261 read(3, "\204\34\3\214\37J}\r/\315e#/\304\32\\\255\37\366\236\232"..., 32768) = 32768

19261 write(5, "\204\34\3\214\37J}\r/\315e#/\304\32\\\255\37\366\236\232"..., 32768) = 32768

19261 time(NULL)                        = 1162218621

19261 read(3, "\20D\311\237\233\4\22z\342\274\335\346\321\330\334ls\361"..., 32768) = 32768

19261 write(5, "\20D\311\237\233\4\22z\342\274\335\346\321\330\334ls\361"..., 32768) = 32768

19261 time(NULL)                        = 1162218621

19261 read(3, "\215\230\316O<\324q9\231\17\315\264\3\202A\316Gj\230\264"..., 32768) = 32768

19261 write(5, "\215\230\316O<\324q9\231\17\315\264\3\202A\316Gj\230\264"..., 32768) = 32768

19261 time(NULL)                        = 1162218621

19261 read(3, "\361%\241\315x\271\231\374\31\253\345p\276C!\'\360\376"..., 32768) = 32768

19261 write(5, "\361%\241\315x\271\231\374\31\253\345p\276C!\'\360\376"..., 32768) = 32768

19261 time(NULL)                        = 1162218621

19261 read(3, "#\255tGc=o\251<k\271\266\201\370Wu\3602B>,\351\207\251"..., 32768) = 32768

19261 write(5, "#\255tGc=o\251<k\271\266\201\370Wu\3602B>,\351\207\251"..., 32768) = 32768

19261 time(NULL)                        = 1162218621

19261 read(3, "5\307\211\3742\270\313G\5\311c\330\r\313\214W\237\212v"..., 32768) = 32768

19261 write(5, "5\307\211\3742\270\313G\5\311c\330\r\313\214W\237\212v"..., 32768) = 32768

19261 time(NULL)                        = 1162218621

19261 read(3, "p\16\177\227\255\4\343\267\320\323\262\270\223\276\344"..., 32768) = 32768

19261 write(5, "p\16\177\227\255\4\343\267\320\323\262\270\223\276\344"..., 32768) = 32768

19261 time(NULL)                        = 1162218621

19261 read(3, "-B\362\326\327\f\32+0X\236\200\366\255\217\0103\vH\303"..., 32768) = 32768

19261 write(5, "-B\362\326\327\f\32+0X\236\200\366\255\217\0103\vH\303"..., 32768) = 32768

19261 time(NULL)                        = 1162218621

19261 read(3, "7S\235\226\354X\223\334\260\343\364\254\352J\322L#\33M"..., 32768) = 32768

19261 write(5, "7S\235\226\354X\223\334\260\343\364\254\352J\322L#\33M"..., 32768) = 32768

19261 time(NULL)                        = 1162218621

19261 read(3, "\36\273$\304\227\332\240\22\2\v\'?\255[\203\266\210\313"..., 32768) = 32768

19261 write(5, "\36\273$\304\227\332\240\22\2\v\'?\255[\203\266\210\313"..., 32768) = 32768

19261 time(NULL)                        = 1162218621

19261 read(3, "\5R\244\340\217\304R\250\317_\317\265\5\332\310@\271l\200"..., 32768) = 32768

19261 write(5, "\5R\244\340\217\304R\250\317_\317\265\5\332\310@\271l\200"..., 32768) = 32768

19261 time(NULL)                        = 1162218621

19261 read(3, "\354\2661\372\314\233\275\304K\35\314\253\3469#\202Cd\373"..., 32768) = 32768

19261 write(5, "\354\2661\372\314\233\275\304K\35\314\253\3469#\202Cd\373"..., 32768) = 32768

19261 time(NULL)                        = 1162218621

19261 read(3, "C\327\35\252\32\261\\\262\206\250y\223-\337\203\203\212"..., 32768) = 32768

19261 write(5, "C\327\35\252\32\261\\\262\206\250y\223-\337\203\203\212"..., 32768) = 32768

19261 time(NULL)                        = 1162218621

19261 read(3, "\'==\251D\254X|\331>\204\321}u\'ylN\257\275\10\'#\251#"..., 32768) = 11642

19261 write(5, "\'==\251D\254X|\331>\204\321}u\'ylN\257\275\10\'#\251#"..., 11642) = 11642

19261 time(NULL)                        = 1162218621

19261 read(3, "", 32768)                = 0

19261 close(5)                          = 0

19261 close(3)                          = 0

19261 close(1)                          = 0

19261 munmap(0xb7fd3000, 4096)          = 0

19261 exit_group(0)                     = ?
```

dal quale non mi pare si possa evincere granché.

Il comando tar da te suggeritomi non cambia l'essenza delle cose: alcuni file vengono scritti in minuscolo.

 *cerri wrote:*   

> Però la cosa che non mi avevi detto al telefono è che si tratta di uno iomega... Non vorrei che qualche driver iomega sia fallato.
> 
> Come lo vedi? Semplice usb-storage?
> 
> Puoi provare a fare la stessa cosa con una chiavetta usb?
> ...

 

Si, il disco è montato tramite usb-storage e non ho accesso fisico alla macchina per poterci montare una chiavetta. Se necessario però intervengo fisicamente.

Ora sto syncando e aggiornando il kernel, dovrò aspettare stasera per riavviare col nuovo kernel (attualmente alla versione 2.6.15 gentoo-sources) per sperare che non sia un problema legato alla versione...

In compenso stanotte ho anche mandato una mail allo sviluppatore di vfat, sperando che mi risponda.

----------

## cerri

L'opzione che menzioni tu, a quanto ne so, vale per la lettura (e la scrittura nel solo caso che un file esista già: ma non in vfat, in fat* non è possibile avere 2 file con lo stesso nome, qualunque siano le maiuscole/minuscole).

Lo strace che hai proposto fa vedere la copia del file DSCN5980.JPG, che però sembra andare a buon fine: quindi non mi aiuta.

Per il tar, almeno adesso sappiamo che è effettivamente un problema del supporto del fs (usb-storage o vfat?) e non del comando cp.

Aggiornaci!

Però puoi montarti un file vfat "virtuale" e provare li la copia che fallisce sullo iomega.

Dai su, che ci hai messo curiosità.   :Laughing: 

----------

## Peach

si ma qui c'è qualcosa di più grosso sotto... non è possibile:

```
# pwd

/mnt/iomega/dir

# ls -l

total 704

-rwxr-xr-x 1 b users 699770 Oct 31 10:23 dscn5980.jpg

# rm dscn5980.jpg

# touch DSCN5980.JPG

# ls -la

ls: dscn5980.jpg: No such file or directory

total 64

drwxr-xr-x  2 battaglia users 32768 Oct 31 10:26 .

drwxr-xr-x 39 battaglia users 32768 Oct 13 14:09 ..
```

 :Exclamation:   :Question: 

secondo me s'è impappinato vfat di brutto.

----------

## cerri

Tutto può essere: rimane il fatto che ancora non sappiamo da cosa venga generato.

Tra l'altro, hai provato a montarlo su una macchina windows e fare un chkdsk da li?

----------

## Peach

 *cerri wrote:*   

> Tra l'altro, hai provato a montarlo su una macchina windows e fare un chkdsk da li?

 

controllato sia con fsck.vfat sia con scandisk che con defrag da win, niente di niente di niente.

l'errore di sopra era per via della flag di mount "check=s" che ora ho tolto... ora semplicemente mi crea i file minuscoli  :Crying or Very sad: 

aggiungo anche:

ho creato un fs vfat locale:

```
# dd if=/dev/zero of=vfat_prova bs=1M count=50

50+0 records in

50+0 records out

52428800 bytes (52 MB) copied, 0.126486 seconds, 415 MB/s

# mkdosfs -v vfat_prova 

mkdosfs 2.11 (12 Mar 2005)

vfat_prova has 64 heads and 32 sectors per track,

logical sector size is 512,

using 0xf8 media descriptor, with 102400 sectors;

file system has 2 16-bit FATs and 4 sectors per cluster.

FAT size is 100 sectors, and provides 25541 clusters.

Root directory contains 512 slots.

Volume ID is 455dd4da, no volume label.

# mount -o loop vfat_prova /mnt/loop/

# mount | grep vfat

/dev/sdb1 on /mnt/iomega type vfat (rw,uid=1000,gid=100,codepage=850,iocharset=iso8859-15)

/root/vfat_prova on /mnt/loop type vfat (rw,loop=/dev/loop0)

# cp -v /home/b/dir/DSCN598* /mnt/loop/

`/home/b/dir/DSCN5980.JPG' -> `/mnt/loop/DSCN5980.JPG'

`/home/b/dir/DSCN5981.JPG' -> `/mnt/loop/DSCN5981.JPG'

`/home/b/dir/DSCN5982.JPG' -> `/mnt/loop/DSCN5982.JPG'

`/home/b/dir/DSCN5983.JPG' -> `/mnt/loop/DSCN5983.JPG'

`/home/b/dir/DSCN5984.JPG' -> `/mnt/loop/DSCN5984.JPG'

`/home/b/dir/DSCN5985.JPG' -> `/mnt/loop/DSCN5985.JPG'

`/home/b/dir/DSCN5986.JPG' -> `/mnt/loop/DSCN5986.JPG'

`/home/b/dir/DSCN5987.JPG' -> `/mnt/loop/DSCN5987.JPG'

`/home/b/dir/DSCN5988.JPG' -> `/mnt/loop/DSCN5988.JPG'

`/home/b/dir/DSCN5989.JPG' -> `/mnt/loop/DSCN5989.JPG'

# ls -l /mnt/loop/

total 6786

-rwxr-xr-x 1 root root 699770 Nov 17 16:28 dscn5980.jpg

-rwxr-xr-x 1 root root 732903 Nov 17 16:28 dscn5981.jpg

-rwxr-xr-x 1 root root 622595 Nov 17 16:28 dscn5982.jpg

-rwxr-xr-x 1 root root 695209 Nov 17 16:28 dscn5983.jpg

-rwxr-xr-x 1 root root 671933 Nov 17 16:28 dscn5984.jpg

-rwxr-xr-x 1 root root 687370 Nov 17 16:28 dscn5985.jpg

-rwxr-xr-x 1 root root 706953 Nov 17 16:28 dscn5986.jpg

-rwxr-xr-x 1 root root 675098 Nov 17 16:28 dscn5987.jpg

-rwxr-xr-x 1 root root 709488 Nov 17 16:28 dscn5988.jpg

-rwxr-xr-x 1 root root 736387 Nov 17 16:28 dscn5989.jpg
```

riproducibile: sempre  :Exclamation: 

[edit] mi hanno fatto notare (grazie Master Brian) che mkdosfs crea di default un fs fat16, ma anche usando come opzione "-F 32" l'errore rimane.

e per controprova:

```
# cp -v /home/b/dir/*\(1\)* /mnt/loop/

`/home/b/dir/DSCN5967(1).JPG' -> `/mnt/loop/DSCN5967(1).JPG'

`/home/b/dir/DSCN5968(1).JPG' -> `/mnt/loop/DSCN5968(1).JPG'

`/home/b/dir/DSCN5969(1).JPG' -> `/mnt/loop/DSCN5969(1).JPG'

`/home/b/dir/DSCN5970(1).JPG' -> `/mnt/loop/DSCN5970(1).JPG'

`/home/b/dir/DSCN5971(1).JPG' -> `/mnt/loop/DSCN5971(1).JPG'

`/home/b/dir/DSCN5972(1).JPG' -> `/mnt/loop/DSCN5972(1).JPG'

`/home/b/dir/DSCN5973(1).JPG' -> `/mnt/loop/DSCN5973(1).JPG'

`/home/b/dir/DSCN5974(1).JPG' -> `/mnt/loop/DSCN5974(1).JPG'

`/home/b/dir/DSCN5975(1).JPG' -> `/mnt/loop/DSCN5975(1).JPG'

`/home/b/dir/DSCN5976(1).JPG' -> `/mnt/loop/DSCN5976(1).JPG'

`/home/b/dir/DSCN5977(1).JPG' -> `/mnt/loop/DSCN5977(1).JPG'

`/home/b/dir/DSCN5978(1).JPG' -> `/mnt/loop/DSCN5978(1).JPG'

`/home/b/dir/DSCN5979(1).JPG' -> `/mnt/loop/DSCN5979(1).JPG'

# ls -l /mnt/loop/

total 15428

-rwxr-xr-x 1 root root 676389 Nov 17 16:33 DSCN5967(1).JPG

-rwxr-xr-x 1 root root 710090 Nov 17 16:33 DSCN5968(1).JPG

-rwxr-xr-x 1 root root 703786 Nov 17 16:33 DSCN5969(1).JPG

-rwxr-xr-x 1 root root 695514 Nov 17 16:33 DSCN5970(1).JPG

-rwxr-xr-x 1 root root 675442 Nov 17 16:33 DSCN5971(1).JPG

-rwxr-xr-x 1 root root 602338 Nov 17 16:33 DSCN5972(1).JPG

-rwxr-xr-x 1 root root 673659 Nov 17 16:33 DSCN5973(1).JPG

-rwxr-xr-x 1 root root 666576 Nov 17 16:33 DSCN5974(1).JPG

-rwxr-xr-x 1 root root 698170 Nov 17 16:33 DSCN5975(1).JPG

-rwxr-xr-x 1 root root 675430 Nov 17 16:33 DSCN5976(1).JPG

-rwxr-xr-x 1 root root 702400 Nov 17 16:33 DSCN5977(1).JPG

-rwxr-xr-x 1 root root 733353 Nov 17 16:33 DSCN5978(1).JPG

-rwxr-xr-x 1 root root 626655 Nov 17 16:33 DSCN5979(1).JPG

-rwxr-xr-x 1 root root 699770 Nov 17 16:28 dscn5980.jpg

-rwxr-xr-x 1 root root 732903 Nov 17 16:28 dscn5981.jpg

-rwxr-xr-x 1 root root 622595 Nov 17 16:28 dscn5982.jpg

-rwxr-xr-x 1 root root 695209 Nov 17 16:28 dscn5983.jpg

-rwxr-xr-x 1 root root 671933 Nov 17 16:28 dscn5984.jpg

-rwxr-xr-x 1 root root 687370 Nov 17 16:28 dscn5985.jpg

-rwxr-xr-x 1 root root 706953 Nov 17 16:28 dscn5986.jpg

-rwxr-xr-x 1 root root 675098 Nov 17 16:28 dscn5987.jpg

-rwxr-xr-x 1 root root 709488 Nov 17 16:28 dscn5988.jpg

-rwxr-xr-x 1 root root 736387 Nov 17 16:28 dscn5989.jpg
```

----------

## Peach

aggiorno finalmente il post con la pseudo soluzione, sicuramente interesserà a qualcuno.

Tornando indietro nel tempo dopo aver inutilmente provato a contattare lo sviluppatore di vfat ho deciso di iscrivermi a LKML (che bello, 300 msg al giorno sono uno spasso quando scarichi la posta).

In questa ml al mio problema mi rispose Ogawa Hirofumi il quale mi fece notare due cose:

1) la copia in minuscolo di nomi di file meno lunghi di 8+3 (dos style) sono dovuti ad una opzione di default di vfat

2) la copia in minuscolo di nomi di file più lunghi di 8+3 sono effettivamente un bug noto della gestione della cache delle dentry.

Tenete presente che tutt'e due i problemi possono verificarsi soprattutto perchè 1) è sempre vera ed è dovuta all'opzione shortnames di vfat impostata a lower; da /usr/src/linux/Documentation/filesystems/vfat.txt si legge che:

```
shortname=lower|win95|winnt|mixed

              -- Shortname display/create setting.

                 lower: convert to lowercase for display,

                        emulate the Windows 95 rule for create.

                 win95: emulate the Windows 95 rule for display/create.

                 winnt: emulate the Windows NT rule for display/create.

                 mixed: emulate the Windows NT rule for display,

                        emulate the Windows 95 rule for create.

                 Default setting is `lower'.
```

e

```
 * 1) Valid characters for the 8.3 format alias are any combination of

 * letters, uppercase alphabets, digits, any of the

 * following special characters:

 *     $ % ' ` - @ { } ~ ! # ( ) & _ ^

 * In this case Longfilename is not stored in disk.

 *

 * WinNT's Extension:

 * File name and extension name is contain uppercase/lowercase

 * only. And it is expressed by CASE_LOWER_BASE and CASE_LOWER_EXT.

 *

 * 2) File name is 8.3 format, but it contain the uppercase and

 * lowercase char, muliti bytes char, etc. In this case numtail is not

 * added, but Longfilename is stored.

 *

 * 3) When the one except for the above, or the following special

 * character are contained:

 *        .   [ ] ; , + =

 * numtail is added, and Longfilename must be stored in disk .
```

soluzione: ricordatevi di aggiungere alle opzioni di mount shortname=winnt sempre e comunque

Per quanto riguarda 2) la possibilità che vi si verifichi facendo delle copie è remota ma la soluzione mi è stata fornita sempre da Hirofumi con la seguente patch:

```
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

---

 fs/vfat/namei.c |   56 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--

 1 file changed, 54 insertions(+), 2 deletions(-)

diff -puN fs/vfat/namei.c~vfat-debug fs/vfat/namei.c

--- linux-2.6/fs/vfat/namei.c~vfat-debug   2006-11-21 23:23:38.000000000 +0900

+++ linux-2.6-hirofumi/fs/vfat/namei.c   2006-11-22 00:36:50.000000000 +0900

@@ -29,6 +29,8 @@ static int vfat_revalidate(struct dentry

 {

    int ret = 1;

 

+   printk("%s: name %s, nd %p, flags %08x\n", __FUNCTION__,

+          dentry->d_name.name, nd, nd ? nd->flags : 0);

    if (!dentry->d_inode &&

        nd && !(nd->flags & LOOKUP_CONTINUE) && (nd->flags & LOOKUP_CREATE))

       /*

@@ -83,6 +85,10 @@ static int vfat_hashi(struct dentry *den

 

    name = qstr->name;

    len = vfat_striptail_len(qstr);

+   printk("%s: parent %p, parent->d_op %p\n",

+          __FUNCTION__, dentry, dentry->d_op);

+   printk("%s: parent %s, name %s\n", __FUNCTION__,

+          dentry->d_name.name, name);

 

    hash = init_name_hash();

    while (len--)

@@ -100,6 +106,9 @@ static int vfat_cmpi(struct dentry *dent

    struct nls_table *t = MSDOS_SB(dentry->d_inode->i_sb)->nls_io;

    unsigned int alen, blen;

 

+   printk("%s: parent %p, parent->d_op %p\n",

+          __FUNCTION__, dentry, dentry->d_op);

+   printk("%s: a %s, b %s\n", __FUNCTION__, a->name, b->name);

    /* A filename cannot end in '.' or we treat it like it has none */

    alen = vfat_striptail_len(a);

    blen = vfat_striptail_len(b);

@@ -659,6 +668,34 @@ static int vfat_add_entry(struct inode *

    if (err)

       goto cleanup;

 

+{

+   int i;

+   for (i = nr_slots - 1; i >= 0; i--) {

+      if (i == (nr_slots - 1)) {

+         struct msdos_dir_entry *de =

+            (struct msdos_dir_entry *)&slots[i];

+         printk("%s: %d: %c%c%c%c%c%c%c%c, %c%c%c\n",

+                __FUNCTION__,

+                nr_slots - 1 - i,

+                de->name[0], de->name[1], de->name[2],

+                de->name[3], de->name[4], de->name[5],

+                de->name[6], de->name[7],

+                de->ext[0], de->ext[1], de->ext[2]);

+         continue;

+      }

+      printk("%s: %d: %c%c%c%c%c, %c%c%c%c%c%c, %c%c",

+             __FUNCTION__,

+             nr_slots - 1 - i,

+             slots[i].name0_4[0], slots[i].name0_4[2],

+             slots[i].name0_4[4], slots[i].name0_4[6],

+             slots[i].name0_4[8],

+             slots[i].name5_10[0], slots[i].name5_10[2],

+             slots[i].name5_10[4], slots[i].name5_10[6],

+             slots[i].name5_10[8], slots[i].name5_10[10],

+             slots[i].name11_12[0], slots[i].name11_12[2]);

+      printk("\n");

+   }

+}

    err = fat_add_entries(dir, slots, nr_slots, sinfo);

    if (err)

       goto cleanup;

@@ -692,6 +729,7 @@ static struct dentry *vfat_lookup(struct

    struct dentry *alias;

    int err, table;

 

+   printk("%s: name %s\n", __FUNCTION__, dentry->d_name.name);

    lock_kernel();

    table = (MSDOS_SB(sb)->options.name_check == 's') ? 2 : 0;

    dentry->d_op = &vfat_dentry_ops[table];

@@ -714,6 +752,7 @@ static struct dentry *vfat_lookup(struct

       else {

          iput(inode);

          unlock_kernel();

+         printk("%s: d_op %p\n", __FUNCTION__, alias->d_op);

          return alias;

       }

 

@@ -726,6 +765,7 @@ error:

    if (dentry) {

       dentry->d_op = &vfat_dentry_ops[table];

       dentry->d_time = dentry->d_parent->d_inode->i_version;

+      printk("%s: d_op %p\n", __FUNCTION__, dentry->d_op);

    }

    return dentry;

 }

@@ -742,6 +782,7 @@ static int vfat_create(struct inode *dir

    lock_kernel();

 

    ts = CURRENT_TIME_SEC;

+   printk("%s: name %s\n", __FUNCTION__, dentry->d_name.name);

    err = vfat_add_entry(dir, &dentry->d_name, 0, 0, &ts, &sinfo);

    if (err)

       goto out;

@@ -761,14 +802,16 @@ static int vfat_create(struct inode *dir

    d_instantiate(dentry, inode);

 out:

    unlock_kernel();

+   printk("%s: err %d\n", __FUNCTION__, err);

    return err;

 }

 

 static int vfat_rmdir(struct inode *dir, struct dentry *dentry)

 {

    struct inode *inode = dentry->d_inode;

+   struct msdos_sb_info *sbi = MSDOS_SB(inode->i_sb);

    struct fat_slot_info sinfo;

-   int err;

+   int err, table;

 

    lock_kernel();

 

@@ -787,6 +830,9 @@ static int vfat_rmdir(struct inode *dir,

    clear_nlink(inode);

    inode->i_mtime = inode->i_atime = CURRENT_TIME_SEC;

    fat_detach(inode);

+   /* need to revalidate for next create */

+   table = (sbi->options.name_check == 's') ? 3 : 1;

+   dentry->d_op = &vfat_dentry_ops[table];

 out:

    unlock_kernel();

 

@@ -796,8 +842,9 @@ out:

 static int vfat_unlink(struct inode *dir, struct dentry *dentry)

 {

    struct inode *inode = dentry->d_inode;

+   struct msdos_sb_info *sbi = MSDOS_SB(inode->i_sb);

    struct fat_slot_info sinfo;

-   int err;

+   int err, table;

 

    lock_kernel();

 

@@ -811,6 +858,9 @@ static int vfat_unlink(struct inode *dir

    clear_nlink(inode);

    inode->i_mtime = inode->i_atime = CURRENT_TIME_SEC;

    fat_detach(inode);

+   /* need to revalidate for next create */

+   table = (sbi->options.name_check == 's') ? 3 : 1;

+   dentry->d_op = &vfat_dentry_ops[table];

 out:

    unlock_kernel();

 

@@ -1019,6 +1069,8 @@ static int vfat_fill_super(struct super_

       sb->s_root->d_op = &vfat_dentry_ops[0];

    else

       sb->s_root->d_op = &vfat_dentry_ops[2];

+   printk("%s: s_root %p, d_op %p\n", __FUNCTION__,

+          sb->s_root, sb->s_root->d_op);

 

    return 0;

 }

_
```

questa patch aggiunge un po' di stampate in dmesg e non so con che tempi verrà inclusa nel kernel e da che versione. Occorrerebbe tenere d'occhio il changelog.

----------

## gutter

Hai postato un bugreport per far aggiungere la patch nei gs?

----------

## Peach

 *gutter wrote:*   

> Hai postato un bugreport per far aggiungere la patch nei gs?

 

buona idea, l'unico problema è che la patch è molto verbosa, nel senso che stampa un casino di debug.

Occorrerebbe dargli una ripulita, magari domando proprio a Hirofumi se magari ha già fatto un commit da qualche parte di questa patch.

----------

## gutter

 *Peach wrote:*   

> 
> 
> buona idea, l'unico problema è che la patch è molto verbosa, nel senso che stampa un casino di debug.
> 
> 

 

Penso basti togliere qualche printk.

 *Peach wrote:*   

> 
> 
> Occorrerebbe dargli una ripulita, magari domando proprio a Hirofumi se magari ha già fatto un commit da qualche parte di questa patch.

 

Si buona idea.

----------

