Hi all
I've recently found a problem with the VFAT module.
I'm working on a gentoo box with kernel 2.6.17 gentoo patched (recently upgraded from 2.6.15)
I've got a samba share on a reiser partition and a daily cron will copy its content to an external usb disk with vfat file system. The copy is done via bash scripting and some checks are done before mirroring the files.
btw _some_ random files are copied lowering all chars in the file name.
Here is an example:
# 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 * /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
even if 'cp' gives correct destination names, an 'ls' shows that this
is not always true.
Here is a second quick experiment I've made:
# 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
if the code will not show up correctly you can find the full code
listings at this url:
http://forums.gentoo.org/viewtopic-t-511205-highlight-.html
(thread in italian, the code is quite self explaining)
Thanks in advance, I can do any further test if you need, and provide any other info on the system.
--
Matteo 'Peach' Pescarin
ICQ UIN = 71110111
Jabber ID = [email protected]
Web Site = http://www.smartart.it
GeCHI = http://www.gechi.it
The Peach <[email protected]> writes:
> I've recently found a problem with the VFAT module.
> I'm working on a gentoo box with kernel 2.6.17 gentoo patched (recently upgraded from 2.6.15)
>
> I've got a samba share on a reiser partition and a daily cron will copy its content to an external usb disk with vfat file system. The copy is done via bash scripting and some checks are done before mirroring the files.
> btw _some_ random files are copied lowering all chars in the file name.
I couldn't reproduce this for now. Could you tell mount options which
you used? and after mount, "cat /proc/mounts", please.
> Here is an example:
>
> # 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 * /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
--
OGAWA Hirofumi <[email protected]>
On Tue, 21 Nov 2006 02:32:43 +0900
OGAWA Hirofumi <[email protected]> wrote:
> I couldn't reproduce this for now. Could you tell mount options which
> you used? and after mount, "cat /proc/mounts", please.
# mount | grep vfat
/dev/sdb1 on /mnt/iomega type vfat (rw,uid=1000,gid=100,codepage=850,iocharset=iso8859-15)
it seems only related to those kind of files, but I don't know how to inspect the "file properties" and why these files behave like this.
As you can see and with a strace made on cp, the files _seems_ to be copied with the correct case, whilst it isn't, as seen with "ls". This and other things let me think is a vfat problem.
--
Matteo 'Peach' Pescarin
ICQ UIN = 71110111
Jabber ID = [email protected]
Web Site = http://www.smartart.it
GeCHI = http://www.gechi.it
Hi,
Have vfat a limit of a file size when copy ?
I tried copy 4.4 Megas to a vfat partition but I got
a limit size exceed
Thanks,
--
Sérgio M. B.
On Wed, 2006-11-22 at 00:46 +0900, OGAWA Hirofumi wrote:
> The Peach <[email protected]> writes:
>
> > On Tue, 21 Nov 2006 02:32:43 +0900
> > OGAWA Hirofumi <[email protected]> wrote:
> >
> >> I couldn't reproduce this for now. Could you tell mount options which
> >> you used? and after mount, "cat /proc/mounts", please.
> >
> > # mount | grep vfat
> > /dev/sdb1 on /mnt/iomega type vfat (rw,uid=1000,gid=100,codepage=850,iocharset=iso8859-15)
> >
> > it seems only related to those kind of files, but I don't know how to inspect the "file properties" and why these files behave like this.
> > As you can see and with a strace made on cp, the files _seems_ to be copied with the correct case, whilst it isn't, as seen with "ls". This and other things let me think is a vfat problem.
>
> Hmm... This may be the dentry cache handling problem of fat.
>
> Can you try the attached debug patch? And if you comment-in the
> following parts, does this problem fix?
>
> @@ -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];
> @@ -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];
Hi S?rgio :)
* Sergio Monteiro Basto <[email protected]> dixit:
> Have vfat a limit of a file size when copy ?
2GB, if I recall correctly. FAT32 itself has a limit of 4GB-1 for
file size, but Linux restricts it even more (don't ask me why).
Ra?l N??ez de Arenas Coronado
--
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
On Wed, 22 Nov 2006 00:46:43 +0900
OGAWA Hirofumi <[email protected]> wrote:
> Can you try the attached debug patch?
Here is the debug for the copy of a normal file over vfat:
# cp -v DSCN5970\(1\).JPG /mnt/loop/
`DSCN5970(1).JPG' -> `/mnt/loop/DSCN5970(1).JPG'
and the output on dmesg:
vfat_hashi: parent d528a514, parent->d_op e0fbf5c0
vfat_hashi: parent /, name DSCN5970(1).JPG
vfat_lookup: name DSCN5970(1).JPG
vfat_hashi: parent d528a514, parent->d_op e0fbf5c0
vfat_hashi: parent /, name DSCN5970(1).JPG
vfat_cmpi: parent d528a514, parent->d_op e0fbf5c0
vfat_cmpi: a DSCN5970(1).JPG, b DSCN5970(1).JPG
vfat_revalidate: name DSCN5970(1).JPG, nd c9f1af30, flags 00000300
vfat_lookup: name DSCN5970(1).JPG
vfat_create: name DSCN5970(1).JPG
vfat_add_entry: 0: DSCN59~1, JPG
vfat_add_entry: 1: DSCN5, 970(1), .J
vfat_add_entry: 2: PG
vfat_create: err 0
and the copy of an "abnormal" file:
# cp -v DSCN5980.JPG /mnt/loop/
`DSCN5980.JPG' -> `/mnt/loop/DSCN5980.JPG'
and its dmesg output:
vfat_hashi: parent d528a514, parent->d_op e0fbf5c0
vfat_hashi: parent /, name DSCN5980.JPG
vfat_cmpi: parent d528a514, parent->d_op e0fbf5c0
vfat_cmpi: a dscn5980.jpg, b DSCN5980.JPG
vfat_hashi: parent d528a514, parent->d_op e0fbf5c0
vfat_hashi: parent /, name DSCN5980.JPG
vfat_cmpi: parent d528a514, parent->d_op e0fbf5c0
vfat_cmpi: a dscn5980.jpg, b DSCN5980.JPG
vfat_create: name dscn5980.jpg
vfat_add_entry: 0: DSCN5980, JPG
vfat_add_entry: 1: dscn5, 980.jp, g
vfat_create: err 0
then:
# ls -l /mnt/loop/
totale 1363
-rwxr-xr-x 1 root root 695514 22 nov 16:21 DSCN5970(1).JPG
-rwxr-xr-x 1 root root 699770 22 nov 16:25 dscn5980.jpg
and its output:
vfat_hashi: parent d528a514, parent->d_op e0fbf5c0
vfat_hashi: parent /, name DSCN5970(1).JPG
vfat_cmpi: parent d528a514, parent->d_op e0fbf5c0
vfat_cmpi: a DSCN5970(1).JPG, b DSCN5970(1).JPG
vfat_revalidate: name DSCN5970(1).JPG, nd c9f18ef8, flags 00000000
vfat_lookup: name DSCN5970(1).JPG
vfat_hashi: parent d528a514, parent->d_op e0fbf5c0
vfat_hashi: parent /, name dscn5980.jpg
vfat_cmpi: parent d528a514, parent->d_op e0fbf5c0
vfat_cmpi: a dscn5980.jpg, b dscn5980.jpg
> And if you comment-in the
> following parts, does this problem fix?
I will repatch asap and post the result.
--
Matteo 'Peach' Pescarin
ICQ UIN = 71110111
Jabber ID = [email protected]
Web Site = http://www.smartart.it
GeCHI = http://www.gechi.it
DervishD <[email protected]> writes:
> * Sergio Monteiro Basto <[email protected]> dixit:
>> Have vfat a limit of a file size when copy ?
>
> 2GB, if I recall correctly. FAT32 itself has a limit of 4GB-1 for
> file size, but Linux restricts it even more (don't ask me why).
It was fixed already, 2.6.x can handle 4GB-1. 2.4.x has limit of
2GB-1 (there is patch).
--
OGAWA Hirofumi <[email protected]>
The Peach <[email protected]> writes:
> and the copy of an "abnormal" file:
>
> # cp -v DSCN5980.JPG /mnt/loop/
> `DSCN5980.JPG' -> `/mnt/loop/DSCN5980.JPG'
>
> and its dmesg output:
> vfat_hashi: parent d528a514, parent->d_op e0fbf5c0
> vfat_hashi: parent /, name DSCN5980.JPG
> vfat_cmpi: parent d528a514, parent->d_op e0fbf5c0
> vfat_cmpi: a dscn5980.jpg, b DSCN5980.JPG
> vfat_hashi: parent d528a514, parent->d_op e0fbf5c0
> vfat_hashi: parent /, name DSCN5980.JPG
> vfat_cmpi: parent d528a514, parent->d_op e0fbf5c0
> vfat_cmpi: a dscn5980.jpg, b DSCN5980.JPG
> vfat_create: name dscn5980.jpg
> vfat_add_entry: 0: DSCN5980, JPG
> vfat_add_entry: 1: dscn5, 980.jp, g
> vfat_create: err 0
This seems to be nasty problem of dentry cache handling.
>> And if you comment-in the
>> following parts, does this problem fix?
>
> I will repatch asap and post the result.
Thanks. Probably instead of some overheads, this patch will fix a problem.
--
OGAWA Hirofumi <[email protected]>
Hi OGAWA :)
* OGAWA Hirofumi <[email protected]> dixit:
> DervishD <[email protected]> writes:
> > * Sergio Monteiro Basto <[email protected]> dixit:
> >> Have vfat a limit of a file size when copy ?
> >
> > 2GB, if I recall correctly. FAT32 itself has a limit of 4GB-1 for
> > file size, but Linux restricts it even more (don't ask me why).
>
> It was fixed already, 2.6.x can handle 4GB-1. 2.4.x has limit of
> 2GB-1 (there is patch).
Cool! Thanks for the information :)
Ra?l N??ez de Arenas Coronado
--
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
On Thu, 23 Nov 2006 01:15:46 +0900
OGAWA Hirofumi <[email protected]> wrote:
> Thanks. Probably instead of some overheads, this patch will fix a problem.
here it is, did the very same experiments than before.
Normal file:
# cp -v DSCN5970\(1\).JPG /mnt/loop/
`DSCN5970(1).JPG' -> `/mnt/loop/DSCN5970(1).JPG'
dmesg:
vfat_hashi: parent d1801e94, parent->d_op e0fbc620
vfat_hashi: parent /, name DSCN5970(1).JPG
vfat_cmpi: parent d1801e94, parent->d_op e0fbc620
vfat_cmpi: a DSCN5970(1).JPG, b DSCN5970(1).JPG
vfat_revalidate: name DSCN5970(1).JPG, nd d65eaeec, flags 00000001
vfat_lookup: name DSCN5970(1).JPG
vfat_hashi: parent d1801e94, parent->d_op e0fbc620
vfat_hashi: parent /, name DSCN5970(1).JPG
vfat_cmpi: parent d1801e94, parent->d_op e0fbc620
vfat_cmpi: a DSCN5970(1).JPG, b DSCN5970(1).JPG
vfat_revalidate: name DSCN5970(1).JPG, nd d65eaf24, flags 00000300
vfat_lookup: name DSCN5970(1).JPG
vfat_create: name DSCN5970(1).JPG
vfat_add_entry: 0: DSCN59~1, JPG
vfat_add_entry: 1: DSCN5, 970(1), .J
vfat_add_entry: 2: PG
vfat_create: err 0
Abnormal file:
# cp -v DSCN5980.JPG /mnt/loop/
`DSCN5980.JPG' -> `/mnt/loop/DSCN5980.JPG'
dmesg:
vfat_hashi: parent d1801e94, parent->d_op e0fbc620
vfat_hashi: parent /, name DSCN5980.JPG
vfat_cmpi: parent d1801e94, parent->d_op e0fbc620
vfat_cmpi: a dscn5980.jpg, b DSCN5980.JPG
vfat_revalidate: name dscn5980.jpg, nd d65eaeec, flags 00000001
vfat_lookup: name DSCN5980.JPG
vfat_hashi: parent d1801e94, parent->d_op e0fbc620
vfat_hashi: parent /, name DSCN5980.JPG
vfat_cmpi: parent d1801e94, parent->d_op e0fbc620
vfat_cmpi: a DSCN5980.JPG, b DSCN5980.JPG
vfat_revalidate: name DSCN5980.JPG, nd d65eaf24, flags 00000300
vfat_lookup: name DSCN5980.JPG
vfat_create: name DSCN5980.JPG
vfat_add_entry: 0: DSCN5980, JPG
vfat_create: err 0
and:
# ls -l /mnt/loop/
totale 1363
-rwxr-xr-x 1 root root 695514 22 nov 20:04 DSCN5970(1).JPG
-rwxr-xr-x 1 root root 699770 22 nov 20:07 dscn5980.jpg
dmesg:
vfat_hashi: parent d1801e94, parent->d_op e0fbc620
vfat_hashi: parent /, name DSCN5970(1).JPG
vfat_cmpi: parent d1801e94, parent->d_op e0fbc620
vfat_cmpi: a DSCN5970(1).JPG, b DSCN5970(1).JPG
vfat_revalidate: name DSCN5970(1).JPG, nd d2512eec, flags 00000000
vfat_lookup: name DSCN5970(1).JPG
vfat_hashi: parent d1801e94, parent->d_op e0fbc620
vfat_hashi: parent /, name dscn5980.jpg
vfat_cmpi: parent d1801e94, parent->d_op e0fbc620
vfat_cmpi: a DSCN5980.JPG, b dscn5980.jpg
vfat_revalidate: name DSCN5980.JPG, nd d2512eec, flags 00000000
:(
--
Matteo 'Peach' Pescarin
ICQ UIN = 71110111
Jabber ID = [email protected]
Web Site = http://www.smartart.it
GeCHI = http://www.gechi.it
The Peach <[email protected]> writes:
> On Thu, 23 Nov 2006 01:15:46 +0900
> OGAWA Hirofumi <[email protected]> wrote:
>
>> Thanks. Probably instead of some overheads, this patch will fix a problem.
>
> here it is, did the very same experiments than before.
> Normal file:
> # cp -v DSCN5970\(1\).JPG /mnt/loop/
> `DSCN5970(1).JPG' -> `/mnt/loop/DSCN5970(1).JPG'
>
> dmesg:
> vfat_hashi: parent d1801e94, parent->d_op e0fbc620
> vfat_hashi: parent /, name DSCN5970(1).JPG
> vfat_cmpi: parent d1801e94, parent->d_op e0fbc620
> vfat_cmpi: a DSCN5970(1).JPG, b DSCN5970(1).JPG
> vfat_revalidate: name DSCN5970(1).JPG, nd d65eaeec, flags 00000001
> vfat_lookup: name DSCN5970(1).JPG
> vfat_hashi: parent d1801e94, parent->d_op e0fbc620
> vfat_hashi: parent /, name DSCN5970(1).JPG
> vfat_cmpi: parent d1801e94, parent->d_op e0fbc620
> vfat_cmpi: a DSCN5970(1).JPG, b DSCN5970(1).JPG
> vfat_revalidate: name DSCN5970(1).JPG, nd d65eaf24, flags 00000300
> vfat_lookup: name DSCN5970(1).JPG
> vfat_create: name DSCN5970(1).JPG
> vfat_add_entry: 0: DSCN59~1, JPG
> vfat_add_entry: 1: DSCN5, 970(1), .J
> vfat_add_entry: 2: PG
> vfat_create: err 0
>
> Abnormal file:
> # cp -v DSCN5980.JPG /mnt/loop/
> `DSCN5980.JPG' -> `/mnt/loop/DSCN5980.JPG'
>
> dmesg:
> vfat_hashi: parent d1801e94, parent->d_op e0fbc620
> vfat_hashi: parent /, name DSCN5980.JPG
> vfat_cmpi: parent d1801e94, parent->d_op e0fbc620
> vfat_cmpi: a dscn5980.jpg, b DSCN5980.JPG
> vfat_revalidate: name dscn5980.jpg, nd d65eaeec, flags 00000001
> vfat_lookup: name DSCN5980.JPG
> vfat_hashi: parent d1801e94, parent->d_op e0fbc620
> vfat_hashi: parent /, name DSCN5980.JPG
> vfat_cmpi: parent d1801e94, parent->d_op e0fbc620
> vfat_cmpi: a DSCN5980.JPG, b DSCN5980.JPG
> vfat_revalidate: name DSCN5980.JPG, nd d65eaf24, flags 00000300
> vfat_lookup: name DSCN5980.JPG
> vfat_create: name DSCN5980.JPG
> vfat_add_entry: 0: DSCN5980, JPG
> vfat_create: err 0
>
> and:
> # ls -l /mnt/loop/
> totale 1363
> -rwxr-xr-x 1 root root 695514 22 nov 20:04 DSCN5970(1).JPG
> -rwxr-xr-x 1 root root 699770 22 nov 20:07 dscn5980.jpg
>
> dmesg:
> vfat_hashi: parent d1801e94, parent->d_op e0fbc620
> vfat_hashi: parent /, name DSCN5970(1).JPG
> vfat_cmpi: parent d1801e94, parent->d_op e0fbc620
> vfat_cmpi: a DSCN5970(1).JPG, b DSCN5970(1).JPG
> vfat_revalidate: name DSCN5970(1).JPG, nd d2512eec, flags 00000000
> vfat_lookup: name DSCN5970(1).JPG
> vfat_hashi: parent d1801e94, parent->d_op e0fbc620
> vfat_hashi: parent /, name dscn5980.jpg
> vfat_cmpi: parent d1801e94, parent->d_op e0fbc620
> vfat_cmpi: a DSCN5980.JPG, b dscn5980.jpg
> vfat_revalidate: name DSCN5980.JPG, nd d2512eec, flags 00000000
This is different thing. Please try "shortname=winnt" or "shortname=mixed"
mount option for shortname (default is shortname=lower).
--
OGAWA Hirofumi <[email protected]>
On Thu, 23 Nov 2006 04:29:15 +0900
OGAWA Hirofumi <[email protected]> wrote:
> This is different thing. Please try "shortname=winnt" or "shortname=mixed"
> mount option for shortname (default is shortname=lower).
finally it works (mounted with shortname=winnt).
Did this patch really solve the issue or was just a "shortname" option problem? I didn't even know that option would made the difference.
now I just should get rid of verbose output.
--
Matteo 'Peach' Pescarin
ICQ UIN = 71110111
Jabber ID = [email protected]
Web Site = http://www.smartart.it
GeCHI = http://www.gechi.it
The Peach <[email protected]> writes:
> On Thu, 23 Nov 2006 04:29:15 +0900
> OGAWA Hirofumi <[email protected]> wrote:
>
>> This is different thing. Please try "shortname=winnt" or "shortname=mixed"
>> mount option for shortname (default is shortname=lower).
>
> finally it works (mounted with shortname=winnt).
> Did this patch really solve the issue or was just a "shortname" option problem? I didn't even know that option would made the difference.
> now I just should get rid of verbose output.
The both of patch and option should be needed. Because the following
filename is not shortname, shortname option doesn't affect.
If you test shortname=winnt without patch, it should still show the
problem of following filename, but it should be rare case though.
Can you test it?
> -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
--
OGAWA Hirofumi <[email protected]>
On Thu, 23 Nov 2006 04:51:56 +0900
OGAWA Hirofumi <[email protected]> wrote:
> The both of patch and option should be needed. Because the following
> filename is not shortname, shortname option doesn't affect.
>
> If you test shortname=winnt without patch, it should still show the
> problem of following filename, but it should be rare case though.
>
> Can you test it?
unfortunately not, the files have been renamed and renaming them back I can't reproduce the magical effect they did before.
Now I will try to rescan for any kind of files with long names and see if with the option on and without the patch it will re-generate that kind of errors they gave me.
I must thank you a lot, maybe a bottle of wine will do it ;)
anyway I didn't get why some files will copy with the right case and other don't. Was it a problem with the dentry table randomly failing in saving the filename? the shortname option in the Docs isn't well accurate in explaining the meaning of "Windows X rule for display/create", I will investigate after having checked the 32 GB of files. thanks again.
--
Matteo 'Peach' Pescarin
ICQ UIN = 71110111
Jabber ID = [email protected]
Web Site = http://www.smartart.it
GeCHI = http://www.gechi.it
On Wed, 2006-11-22 at 15:53 +0100, DervishD wrote:
> Hi S?rgio :)
>
> * Sergio Monteiro Basto <[email protected]> dixit:
> > Have vfat a limit of a file size when copy ?
>
> 2GB, if I recall correctly. FAT32 itself has a limit of 4GB-1 for
> file size, but Linux restricts it even more (don't ask me why).
May I say that FAT32 have a bigger limit (at least on last Windows).
The file in question have 4491771904 bytes, 4288 mega bytes , 4.2G or
4.5G if use powers of 1000.
I copy the file from one FAT32 to my computer (ext3), now I would like
to copy to other FAT32. But I just copy 4096 mega bytes (and terminate
with an error of limit file exceed) .
Have you a solution for the case ? Now I have the file in ext3 and I
couldn't copy to any vfat :)
I have a solution with cifs or smbmount, but in same computer ?
Thanks,
>
> Ra?l N??ez de Arenas Coronado
>
--
S?rgio M.B.
Hi,
We encountered this problem before,it did being caused by dcache.
When creating files, VFS would check the dcache first and pass the dentry
it found there to vfat_create(). Instead of dentry , using the path info
passed by user solved the problem.
--- namei.c 2006-11-18 18:41:58.000000000 +0900
+++ namei.c.new 2006-11-23 12:45:34.000000000 +0900
@@ -742,7 +742,7 @@
lock_kernel();
ts = CURRENT_TIME_SEC;
- err = vfat_add_entry(dir, &dentry->d_name, 0, 0, &ts, &sinfo);
+ err = vfat_add_entry(dir, &nd->last, 0, 0, &ts, &sinfo);
if (err)
goto out;
dir->i_version++;
From: OGAWA Hirofumi <[email protected]>
Subject: Re: bug? VFAT copy problem
Date: Wed, 22 Nov 2006 00:46:43 +0900
> The Peach <[email protected]> writes:
>
> > On Tue, 21 Nov 2006 02:32:43 +0900
> > OGAWA Hirofumi <[email protected]> wrote:
> >
> >> I couldn't reproduce this for now. Could you tell mount options which
> >> you used? and after mount, "cat /proc/mounts", please.
> >
> > # mount | grep vfat
> > /dev/sdb1 on /mnt/iomega type vfat (rw,uid=1000,gid=100,codepage=850,iocharset=iso8859-15)
> >
> > it seems only related to those kind of files, but I don't know how to inspect the "file properties" and why these files behave like this.
> > As you can see and with a strace made on cp, the files _seems_ to be copied with the correct case, whilst it isn't, as seen with "ls". This and other things let me think is a vfat problem.
>
> Hmm... This may be the dentry cache handling problem of fat.
>
> Can you try the attached debug patch? And if you comment-in the
> following parts, does this problem fix?
>
> @@ -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];
> @@ -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];
> --
> OGAWA Hirofumi <[email protected]>
>
Hi S?rgio :)
* Sergio Monteiro Basto <[email protected]> dixit:
> On Wed, 2006-11-22 at 15:53 +0100, DervishD wrote:
> > * Sergio Monteiro Basto <[email protected]> dixit:
> > > Have vfat a limit of a file size when copy ?
> >
> > 2GB, if I recall correctly. FAT32 itself has a limit of 4GB-1 for
> > file size, but Linux restricts it even more (don't ask me why).
>
> May I say that FAT32 have a bigger limit (at least on last Windows).
I really don't know, but from microsoft technical information
(the first or second hit when googling for "FAT32 size limit"), the
limit they specify in FAT32 is 2^32-1.
I may be wrong, but with 32 bits you cannot address more than
2^32 bytes, I don't know how can you create a bigger-than-4Gb file in
a FAT32 filesystem without resorting to tricks like this:
forum.doom9.org/archive/index.php/t-20689.html
Looks like FAT-32 (don't ask me how because I don't know the
internals) can store a file bigger than 4GB, but you cannot *save*
it. So you won't be able to put the file you have back to any FAT32
filesystem, I'm afraid.
> Have you a solution for the case ? Now I have the file in ext3 and
> I couldn't copy to any vfat :)
No, I don't have any idea about how to do it, sorry :(
> I have a solution with cifs or smbmount, but in same computer ?
I doubt. That limit is a hard limit as far as I know. Google for
"FAT32 limit" and you'll get a lot of answers telling it. I don't
really know how did you get a bigger than 4GB file saved in a FAT32
filesystem in the first place ;))
Ra?l N??ez de Arenas Coronado
--
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
[email protected] writes:
> We encountered this problem before,it did being caused by dcache.
> When creating files, VFS would check the dcache first and pass the dentry
> it found there to vfat_create(). Instead of dentry , using the path info
> passed by user solved the problem.
>
> --- namei.c 2006-11-18 18:41:58.000000000 +0900
> +++ namei.c.new 2006-11-23 12:45:34.000000000 +0900
> @@ -742,7 +742,7 @@
> lock_kernel();
>
> ts = CURRENT_TIME_SEC;
> - err = vfat_add_entry(dir, &dentry->d_name, 0, 0, &ts, &sinfo);
> + err = vfat_add_entry(dir, &nd->last, 0, 0, &ts, &sinfo);
> if (err)
> goto out;
> dir->i_version++;
>
Interesting hack. However, mkdir() and rename() have same problem.
--
OGAWA Hirofumi <[email protected]>
On Thu, 23 Nov 2006 10:13:01 +0100
DervishD <[email protected]> wrote:
> > Have you a solution for the case ? Now I have the file in ext3 and
> > I couldn't copy to any vfat :)
>
> No, I don't have any idea about how to do it, sorry :(
>
maybe using ntfs-3g driver with fuse or use the extX windows driver (if the need was read from Windows).
I'm feeling quite confortable with the first solution, whilst the second is suggested by the official linux ntfs support page
--
Matteo 'Peach' Pescarin
ICQ UIN = 71110111
Jabber ID = [email protected]
Web Site = http://www.smartart.it
GeCHI = http://www.gechi.it
The Peach <[email protected]> writes:
> anyway I didn't get why some files will copy with the right case and
> other don't. Was it a problem with the dentry table randomly failing
> in saving the filename?
If it's shortname (the detail of shortname is following), the
"shortname=" option solves a problem. If it's longname (not
shortname), the patch solves a problem. The your case seems to need both.
* 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 .
--
OGAWA Hirofumi <[email protected]>
DervishD <[email protected]> writes:
> * Sergio Monteiro Basto <[email protected]> dixit:
>> On Wed, 2006-11-22 at 15:53 +0100, DervishD wrote:
>> > * Sergio Monteiro Basto <[email protected]> dixit:
>> > > Have vfat a limit of a file size when copy ?
>> >
>> > 2GB, if I recall correctly. FAT32 itself has a limit of 4GB-1 for
>> > file size, but Linux restricts it even more (don't ask me why).
>>
>> May I say that FAT32 have a bigger limit (at least on last Windows).
>
> I really don't know, but from microsoft technical information
> (the first or second hit when googling for "FAT32 size limit"), the
> limit they specify in FAT32 is 2^32-1.
>
> I may be wrong, but with 32 bits you cannot address more than
> 2^32 bytes, I don't know how can you create a bigger-than-4Gb file in
> a FAT32 filesystem without resorting to tricks like this:
>
> forum.doom9.org/archive/index.php/t-20689.html
>
> Looks like FAT-32 (don't ask me how because I don't know the
> internals) can store a file bigger than 4GB, but you cannot *save*
> it. So you won't be able to put the file you have back to any FAT32
> filesystem, I'm afraid.
Right. FAT's size field is 32bit, so *file* of FAT has limit of 4GB-1.
(Since directory doesn't have size, in theoretically it can exceed 4GB-1)
Hm.. Maybe MS added a new hack to FAT..?
--
OGAWA Hirofumi <[email protected]>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
OGAWA Hirofumi escreveu:
> Right. FAT's size field is 32bit, so *file* of FAT has limit of 4GB-1.
> (Since directory doesn't have size, in theoretically it can exceed 4GB-1)
>
> Hm.. Maybe MS added a new hack to FAT..?
Ogawa, MS don't added a new hack to FAT32... This file system don't
support file size with more than 4Gb:
<http://msdn2.microsoft.com/en-us/library/aa365678.aspx>
Best Regards,
- --
Renato S. Yamane
Fingerprint: 68AE A381 938A F4B9 8A23 D11A E351 5030 D420 515A
PGP Server: http://pgp.mit.edu/ --> KeyID: 0xD420515A
<http://www.renatoyamane.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFFZYsZ41FQMNQgUVoRAresAJ0cyYTTOMr9Zrik2ojqquUC8wwEwgCfTe1g
93wBDWCheZSSfMyiBHIfmNc=
=kmsy
-----END PGP SIGNATURE-----
"Renato S. Yamane" <[email protected]> writes:
> OGAWA Hirofumi escreveu:
>> Right. FAT's size field is 32bit, so *file* of FAT has limit of 4GB-1.
>> (Since directory doesn't have size, in theoretically it can exceed 4GB-1)
>>
>> Hm.. Maybe MS added a new hack to FAT..?
>
> Ogawa, MS don't added a new hack to FAT32... This file system don't
> support file size with more than 4Gb:
> <http://msdn2.microsoft.com/en-us/library/aa365678.aspx>
Thanks. Yes. However, Sergio's windows seems to handle file size more
than 4GB-1...
--
OGAWA Hirofumi <[email protected]>
Hi Matteo :)
* The Peach <[email protected]> dixit:
> DervishD <[email protected]> wrote:
>
> > > Have you a solution for the case ? Now I have the file in ext3
> > > and I couldn't copy to any vfat :)
> >
> > No, I don't have any idea about how to do it, sorry :(
> >
>
> maybe using ntfs-3g driver with fuse or use the extX windows driver
> (if the need was read from Windows). I'm feeling quite confortable
> with the first solution, whilst the second is suggested by the
> official linux ntfs support page
Of course, such options exist, but Sergio was asking to write to
a FAT-32, so... Myself, I use ext2 for my external disks if I can,
and I install the ext2-ifs driver for windows to read them. It works
like a charm.
Ra?l N??ez de Arenas Coronado
--
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
On Thu, 2006-11-23 at 20:59 +0900, OGAWA Hirofumi wrote:
> . Yes. However, Sergio's windows seems to handle file size more
> than 4GB-1..
I not finish my tests yet, but so far I was wrong.
Could happened that transfer never had pass by one FAT32.
Thanks,
--
Sérgio M. B.