[PATCH] parport netmos 9845 & 9855 1P4S fixes

[PATCH] parport netmos 9845 & 9855 1P4S fixes

[Philippe De Muyter]

Hello list,

--

netmos serial/parallel adapters come in different flavour differing only
by the number of parallel and serial ports, which are encoded in the
subdevice ID.

Last fix of Christian Pellegrin for 9855 2P2S broke support for 9855 1P4S,
and works only by side-effect for the first parallel port of a 2P2S,
as it is found by reading the second addr entry of
(struct parport_pc_pci) cards[netmos_9855], which is not initialized.

netmos_9xx5_combo entry in (struct parport_pc_pci) cards[], which is used
for a 9845 1P4S should also be fixed when there are 4 serial ports
because it currently gives 2 as BAR index for the parallel port,
while, in this case, BAR 2 is the 3rd serial port and the parallel port
is at BAR 4.

I fixed 9845 1P4S and 9855 1P4S support, while preserving 9855 2P2S support,
by creating and using a netmos_9855_2p entry for 9855 boards with 2 parallel
ports for 9855 2P2S and 9855 2P0S boards,
and by allowing netmos_parallel_init to change not only the number of
parallel ports (0 or 1), but also the BAR index of the parallel port
when the serial ports are before the parallel port.

PS: the netmos_9855_2p entry in
(struct pciserial_board) pci_parport_serial_boards[] is needed because
netmos_parallel_init has no clean way to replace FL_BASE2 by FL_BASE4
based on the number of parallel ports in the card.

Tested with a 9845 1P4S and a 9855 1P4S board.

Signed-off-by: Philippe De Muyter <phdm@macqel.be>

diff --git a/drivers/parport/parport_serial.c b/drivers/parport/parport_serial.c
--- a/drivers/parport/parport_serial.c
+++ b/drivers/parport/parport_serial.c
@@ -30,6 +30,7 @@ enum parport_pc_pci_cards {
 	titan_210l,
 	netmos_9xx5_combo,
 	netmos_9855,
+	netmos_9855_2p,
 	avlab_1s1p,
 	avlab_1s2p,
 	avlab_2s1p,
@@ -62,7 +63,7 @@ struct parport_pc_pci {
 				struct parport_pc_pci *card, int failed);
 };
 
-static int __devinit netmos_parallel_init(struct pci_dev *dev, struct parport_pc_pci *card, int autoirq, int autodma)
+static int __devinit netmos_parallel_init(struct pci_dev *dev, struct parport_pc_pci *par, int autoirq, int autodma)
 {
 	/* the rule described below doesn't hold for this device */
 	if (dev->device == PCI_DEVICE_ID_NETMOS_9835 &&
@@ -74,9 +75,17 @@ static int __devinit netmos_parallel_ini
 	 * and serial ports.  The form is 0x00PS, where <P> is the number of
 	 * parallel ports and <S> is the number of serial ports.
 	 */
-	card->numports = (dev->subsystem_device & 0xf0) >> 4;
-	if (card->numports > ARRAY_SIZE(card->addr))
-		card->numports = ARRAY_SIZE(card->addr);
+	par->numports = (dev->subsystem_device & 0xf0) >> 4;
+	if (par->numports > ARRAY_SIZE(par->addr))
+		par->numports = ARRAY_SIZE(par->addr);
+	/*
+	 * This function is currently only called for cards with up to
+	 * one parallel port.
+	 * Parallel port BAR is either before or after serial ports BARS;
+	 * hence, lo should be either 0 or equal to the number of serial ports.
+	 */
+	if (par->addr[0].lo != 0)
+		par->addr[0].lo = dev->subsystem_device & 0xf;
 	return 0;
 }
 
@@ -84,7 +93,8 @@ static struct parport_pc_pci cards[] __d
 	/* titan_110l */		{ 1, { { 3, -1 }, } },
 	/* titan_210l */		{ 1, { { 3, -1 }, } },
 	/* netmos_9xx5_combo */		{ 1, { { 2, -1 }, }, netmos_parallel_init },
-	/* netmos_9855 */		{ 1, { { 2, -1 }, }, netmos_parallel_init },
+	/* netmos_9855 */		{ 1, { { 0, -1 }, }, netmos_parallel_init },
+	/* netmos_9855_2p */		{ 2, { { 0, -1 }, { 2, -1 }, } },
 	/* avlab_1s1p     */		{ 1, { { 1, 2}, } },
 	/* avlab_1s2p     */		{ 2, { { 1, 2}, { 3, 4 },} },
 	/* avlab_2s1p     */		{ 1, { { 2, 3}, } },
@@ -109,6 +119,10 @@ static struct pci_device_id parport_seri
 	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, netmos_9xx5_combo },
 	{ PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9845,
 	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, netmos_9xx5_combo },
+	{ PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9855,
+	  0x1000, 0x0020, 0, 0, netmos_9855_2p },
+	{ PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9855,
+	  0x1000, 0x0022, 0, 0, netmos_9855_2p },
 	{ PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9855,
 	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, netmos_9855 },
 	/* PCI_VENDOR_ID_AVLAB/Intek21 has another bunch of cards ...*/
@@ -192,6 +206,12 @@ static struct pciserial_board pci_parpor
 		.uart_offset	= 8,
 	},
 	[netmos_9855] = {
+		.flags		= FL_BASE2 | FL_BASE_BARS,
+		.num_ports	= 1,
+		.base_baud	= 115200,
+		.uart_offset	= 8,
+	},
+	[netmos_9855_2p] = {
 		.flags		= FL_BASE4 | FL_BASE_BARS,
 		.num_ports	= 1,
 		.base_baud	= 115200,

Re: [PATCH] parport netmos 9845 & 9855 1P4S fixes

[Philippe De Muyter]

Hello list,

Sorry for the resend.  I had forgotten to cc Christian Pellegrin,
and have rephrased somewhat the comment.

Christian, can you verify that the patch below works for your
netmos 9855 2P2S board ?

Philippe

--

netmos serial/parallel adapters come in different flavour differing only
by the number of parallel and serial ports, which are encoded in the
subdevice ID.

Last fix of Christian Pellegrin for 9855 2P2S broke support for 9855 1P4S,
and works only by side-effect for the first parallel port of a 2P2S,
as this first parallel port is found by reading the second addr entry of
(struct parport_pc_pci) cards[netmos_9855], which is not initialized, and
hence has value 0, which happens to be the BAR of the first parallel port.

netmos_9xx5_combo entry in (struct parport_pc_pci) cards[], which is used
for a 9845 1P4S must also be fixed for the parallel port support when there
are 4 serial ports because this entry currently gives 2 as BAR index for
the parallel port.  Actually, in this case, BAR 2 is the 3rd serial port
while the parallel port is at BAR 4.

I fixed 9845 1P4S and 9855 1P4S support, while preserving 9855 2P2S support,
- by creating a netmos_9855_2p entry and using it for 9855 boards with
2 parallel ports : 9855 2P2S and 9855 2P0S boards,
- and by allowing netmos_parallel_init to change not only the number of
parallel ports (0 or 1), but making it also change the BAR index of the
parallel port when the serial ports are before the parallel port.

PS: the netmos_9855_2p entry in
(struct pciserial_board) pci_parport_serial_boards[] is needed because
netmos_parallel_init has no clean way to replace FL_BASE2 by FL_BASE4
in the description of the serial ports in function of the number of
parallel ports on the card.

Tested with a 9845 1P4S and a 9855 1P4S board.

Signed-off-by: Philippe De Muyter <phdm@macqel.be>

diff --git a/drivers/parport/parport_serial.c b/drivers/parport/parport_serial.c
--- a/drivers/parport/parport_serial.c
+++ b/drivers/parport/parport_serial.c
@@ -30,6 +30,7 @@ enum parport_pc_pci_cards {
 	titan_210l,
 	netmos_9xx5_combo,
 	netmos_9855,
+	netmos_9855_2p,
 	avlab_1s1p,
 	avlab_1s2p,
 	avlab_2s1p,
@@ -62,7 +63,7 @@ struct parport_pc_pci {
 				struct parport_pc_pci *card, int failed);
 };
 
-static int __devinit netmos_parallel_init(struct pci_dev *dev, struct parport_pc_pci *card, int autoirq, int autodma)
+static int __devinit netmos_parallel_init(struct pci_dev *dev, struct parport_pc_pci *par, int autoirq, int autodma)
 {
 	/* the rule described below doesn't hold for this device */
 	if (dev->device == PCI_DEVICE_ID_NETMOS_9835 &&
@@ -74,9 +75,17 @@ static int __devinit netmos_parallel_ini
 	 * and serial ports.  The form is 0x00PS, where <P> is the number of
 	 * parallel ports and <S> is the number of serial ports.
 	 */
-	card->numports = (dev->subsystem_device & 0xf0) >> 4;
-	if (card->numports > ARRAY_SIZE(card->addr))
-		card->numports = ARRAY_SIZE(card->addr);
+	par->numports = (dev->subsystem_device & 0xf0) >> 4;
+	if (par->numports > ARRAY_SIZE(par->addr))
+		par->numports = ARRAY_SIZE(par->addr);
+	/*
+	 * This function is currently only called for cards with up to
+	 * one parallel port.
+	 * Parallel port BAR is either before or after serial ports BARS;
+	 * hence, lo should be either 0 or equal to the number of serial ports.
+	 */
+	if (par->addr[0].lo != 0)
+		par->addr[0].lo = dev->subsystem_device & 0xf;
 	return 0;
 }
 
@@ -84,7 +93,8 @@ static struct parport_pc_pci cards[] __d
 	/* titan_110l */		{ 1, { { 3, -1 }, } },
 	/* titan_210l */		{ 1, { { 3, -1 }, } },
 	/* netmos_9xx5_combo */		{ 1, { { 2, -1 }, }, netmos_parallel_init },
-	/* netmos_9855 */		{ 1, { { 2, -1 }, }, netmos_parallel_init },
+	/* netmos_9855 */		{ 1, { { 0, -1 }, }, netmos_parallel_init },
+	/* netmos_9855_2p */		{ 2, { { 0, -1 }, { 2, -1 }, } },
 	/* avlab_1s1p     */		{ 1, { { 1, 2}, } },
 	/* avlab_1s2p     */		{ 2, { { 1, 2}, { 3, 4 },} },
 	/* avlab_2s1p     */		{ 1, { { 2, 3}, } },
@@ -109,6 +119,10 @@ static struct pci_device_id parport_seri
 	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, netmos_9xx5_combo },
 	{ PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9845,
 	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, netmos_9xx5_combo },
+	{ PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9855,
+	  0x1000, 0x0020, 0, 0, netmos_9855_2p },
+	{ PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9855,
+	  0x1000, 0x0022, 0, 0, netmos_9855_2p },
 	{ PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9855,
 	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, netmos_9855 },
 	/* PCI_VENDOR_ID_AVLAB/Intek21 has another bunch of cards ...*/
@@ -192,6 +206,12 @@ static struct pciserial_board pci_parpor
 		.uart_offset	= 8,
 	},
 	[netmos_9855] = {
+		.flags		= FL_BASE2 | FL_BASE_BARS,
+		.num_ports	= 1,
+		.base_baud	= 115200,
+		.uart_offset	= 8,
+	},
+	[netmos_9855_2p] = {
 		.flags		= FL_BASE4 | FL_BASE_BARS,
 		.num_ports	= 1,
 		.base_baud	= 115200,

Re: [PATCH] parport netmos 9845 & 9855 1P4S fixes

[christian pellegrin]

On Mon, Mar 23, 2009 at 9:50 AM, Philippe De Muyter <phdm@macqel.be> wrote:
> Hello list,
>

Hi,

> Christian, can you verify that the patch below works for your
> netmos 9855 2P2S board ?

I compiled a kernel with this patch and I see both serial and both
parallel ports in dmesg. I tested the serial ports and they work.
Unfortunately I don't have any device around to test the parallel
ports. You know, USB killed the pport stars.

> Last fix of Christian Pellegrin for 9855 2P2S broke support for 9855 1P4S,
> and works only by side-effect for the first parallel port of a 2P2S,

sorry for that, I didn't know about the 1P4S version. This is the
reason why I changed netmos9855 entry directyl.

-- 
Christian Pellegrin, see http://www.evolware.org/chri/
"Real Programmers don't play tennis, or any other sport which requires
you to change clothes. Mountain climbing is OK, and Real Programmers
wear their climbing boots to work in case a mountain should suddenly
spring up in the middle of the computer room."

Re: [PATCH] parport netmos 9845 & 9855 1P4S fixes

[Philippe De Muyter]

On Mon, Mar 23, 2009 at 02:21:59PM +0100, christian pellegrin wrote:
> On Mon, Mar 23, 2009 at 9:50 AM, Philippe De Muyter <phdm@macqel.be> wrote:
> > Hello list,
> >
> 
> Hi,
> 
> > Christian, can you verify that the patch below works for your
> > netmos 9855 2P2S board ?
> 
> I compiled a kernel with this patch and I see both serial and both
> parallel ports in dmesg. I tested the serial ports and they work.

Thanks for your quick feedback.

> Unfortunately I don't have any device around to test the parallel
> ports. You know, USB killed the pport stars.

I only use parallel ports for hardware debuggers.

> 
> > Last fix of Christian Pellegrin for 9855 2P2S broke support for 9855 1P4S,
> > and works only by side-effect for the first parallel port of a 2P2S,
> 
> sorry for that, I didn't know about the 1P4S version. This is the
> reason why I changed netmos9855 entry directyl.

No problem.  I have not been affected.  I needed to fix the 9845 1P4S
support, but as I have also a computer with a 9855 1P4S, I did some
code inspection there also and found your change.

Have a nice day

Philippe

[PATCH] parport netmos 9845 & 9855 1P4S fixes

[Philippe De Muyter]

Hello list,

The same patch, with an additional Tested-by, after the positive feedback
of Christian Pellegrin.

Philippe

--

netmos serial/parallel adapters come in different flavour differing only
by the number of parallel and serial ports, which are encoded in the
subdevice ID.

Last fix of Christian Pellegrin for 9855 2P2S broke support for 9855 1P4S,
and works only by side-effect for the first parallel port of a 2P2S,
as this first parallel port is found by reading the second addr entry of
(struct parport_pc_pci) cards[netmos_9855], which is not initialized, and
hence has value 0, which happens to be the BAR of the first parallel port.

netmos_9xx5_combo entry in (struct parport_pc_pci) cards[], which is used
for a 9845 1P4S must also be fixed for the parallel port support when there
are 4 serial ports because this entry currently gives 2 as BAR index for
the parallel port.  Actually, in this case, BAR 2 is the 3rd serial port
while the parallel port is at BAR 4.

I fixed 9845 1P4S and 9855 1P4S support, while preserving 9855 2P2S support,
- by creating a netmos_9855_2p entry and using it for 9855 boards with
2 parallel ports : 9855 2P2S and 9855 2P0S boards,
- and by allowing netmos_parallel_init to change not only the number of
parallel ports (0 or 1), but making it also change the BAR index of the
parallel port when the serial ports are before the parallel port.

PS: the netmos_9855_2p entry in
(struct pciserial_board) pci_parport_serial_boards[] is needed because
netmos_parallel_init has no clean way to replace FL_BASE2 by FL_BASE4
in the description of the serial ports in function of the number of
parallel ports on the card.

Tested with 9845 1P4S, 9855 1P4S and 9855 2P2S boards.

Signed-off-by: Philippe De Muyter <phdm@macqel.be>
Tested-by: Christian Pellegrin <chripell@fsfe.org>

diff --git a/drivers/parport/parport_serial.c b/drivers/parport/parport_serial.c
--- a/drivers/parport/parport_serial.c
+++ b/drivers/parport/parport_serial.c
@@ -30,6 +30,7 @@ enum parport_pc_pci_cards {
 	titan_210l,
 	netmos_9xx5_combo,
 	netmos_9855,
+	netmos_9855_2p,
 	avlab_1s1p,
 	avlab_1s2p,
 	avlab_2s1p,
@@ -62,7 +63,7 @@ struct parport_pc_pci {
 				struct parport_pc_pci *card, int failed);
 };
 
-static int __devinit netmos_parallel_init(struct pci_dev *dev, struct parport_pc_pci *card, int autoirq, int autodma)
+static int __devinit netmos_parallel_init(struct pci_dev *dev, struct parport_pc_pci *par, int autoirq, int autodma)
 {
 	/* the rule described below doesn't hold for this device */
 	if (dev->device == PCI_DEVICE_ID_NETMOS_9835 &&
@@ -74,9 +75,17 @@ static int __devinit netmos_parallel_ini
 	 * and serial ports.  The form is 0x00PS, where <P> is the number of
 	 * parallel ports and <S> is the number of serial ports.
 	 */
-	card->numports = (dev->subsystem_device & 0xf0) >> 4;
-	if (card->numports > ARRAY_SIZE(card->addr))
-		card->numports = ARRAY_SIZE(card->addr);
+	par->numports = (dev->subsystem_device & 0xf0) >> 4;
+	if (par->numports > ARRAY_SIZE(par->addr))
+		par->numports = ARRAY_SIZE(par->addr);
+	/*
+	 * This function is currently only called for cards with up to
+	 * one parallel port.
+	 * Parallel port BAR is either before or after serial ports BARS;
+	 * hence, lo should be either 0 or equal to the number of serial ports.
+	 */
+	if (par->addr[0].lo != 0)
+		par->addr[0].lo = dev->subsystem_device & 0xf;
 	return 0;
 }
 
@@ -84,7 +93,8 @@ static struct parport_pc_pci cards[] __d
 	/* titan_110l */		{ 1, { { 3, -1 }, } },
 	/* titan_210l */		{ 1, { { 3, -1 }, } },
 	/* netmos_9xx5_combo */		{ 1, { { 2, -1 }, }, netmos_parallel_init },
-	/* netmos_9855 */		{ 1, { { 2, -1 }, }, netmos_parallel_init },
+	/* netmos_9855 */		{ 1, { { 0, -1 }, }, netmos_parallel_init },
+	/* netmos_9855_2p */		{ 2, { { 0, -1 }, { 2, -1 }, } },
 	/* avlab_1s1p     */		{ 1, { { 1, 2}, } },
 	/* avlab_1s2p     */		{ 2, { { 1, 2}, { 3, 4 },} },
 	/* avlab_2s1p     */		{ 1, { { 2, 3}, } },
@@ -109,6 +119,10 @@ static struct pci_device_id parport_seri
 	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, netmos_9xx5_combo },
 	{ PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9845,
 	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, netmos_9xx5_combo },
+	{ PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9855,
+	  0x1000, 0x0020, 0, 0, netmos_9855_2p },
+	{ PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9855,
+	  0x1000, 0x0022, 0, 0, netmos_9855_2p },
 	{ PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9855,
 	  PCI_ANY_ID, PCI_ANY_ID, 0, 0, netmos_9855 },
 	/* PCI_VENDOR_ID_AVLAB/Intek21 has another bunch of cards ...*/
@@ -192,6 +206,12 @@ static struct pciserial_board pci_parpor
 		.uart_offset	= 8,
 	},
 	[netmos_9855] = {
+		.flags		= FL_BASE2 | FL_BASE_BARS,
+		.num_ports	= 1,
+		.base_baud	= 115200,
+		.uart_offset	= 8,
+	},
+	[netmos_9855_2p] = {
 		.flags		= FL_BASE4 | FL_BASE_BARS,
 		.num_ports	= 1,
 		.base_baud	= 115200,

-- 
Philippe De Muyter  phdm at macqel dot be  Tel +32 27029044
Macq Electronique SA  rue de l'Aeronef 2  B-1140 Bruxelles  Fax +32 27029077

[PATCH RFC] vfat and Simon_&_Garfunkel-Wednesday_Morning,_3_a.m.

[Philippe De Muyter]

Hello vfat guru's

I have an IOMEGA home network hard disk that I can connect either by
ethernet (ftp or cifs) or by USB. because of the ftp server mode
firmware, I must keep it formatted as a vfat filesystem.

I have copied my music files on it using the ftp mode.  Using the same
ftp mode, I can also retrieve my music files without problem, and
when I list them, they have the exact names that they had on my linux
ext3 partition.

When I connected this disk via USB, now relying on the vfat module
of linux, there were some directories that I could not reread.  The
common factor of these directories names is that they end with one or
more dots, e.g.

	Simon_&_Garfunkel-Wednesday_Morning,_3_a.m.

If I issue the `ls' or `find' command, I get this strange message :

find: ./Simon_&_Garfunkel-Wednesday_Morning,_3_a.m.: No such file or directory

Adding printk's in `fat_search_long' revealed that on this disk, the
file/directory NAMES ENDING WITH DOTS ARE STORED WITH THEIR TRAILING DOTS.

Here is a patch squetch that make accessing my
 Simon_&_Garfunkel-Wednesday_Morning,_3_a.m. directory possible, but I
don't know if storing long filenames ending with dot's should not also
be fixed.

Signed-off-by: Philippe De Muyter <phdm@macqel.be>

diff -r f2c5827a8d44 fs/fat/namei_vfat.c
--- a/fs/fat/namei_vfat.c	Mon Aug 31 17:44:05 2009 -1000
+++ b/fs/fat/namei_vfat.c	Fri Sep 25 21:30:36 2009 +0200
@@ -702,10 +702,7 @@
 static int vfat_find(struct inode *dir, struct qstr *qname,
 		     struct fat_slot_info *sinfo)
 {
-	unsigned int len = vfat_striptail_len(qname);
-	if (len == 0)
-		return -ENOENT;
-	return fat_search_long(dir, qname->name, len, sinfo);
+	return fat_search_long(dir, qname->name, qname->len, sinfo);
 }
 
 static struct dentry *vfat_lookup(struct inode *dir, struct dentry *dentry,

Re: [PATCH RFC] vfat and Simon_&_Garfunkel-Wednesday_Morning,_3_a.m.

[OGAWA Hirofumi]

Philippe De Muyter <phdm@macqel.be> writes:

> I have an IOMEGA home network hard disk that I can connect either by
> ethernet (ftp or cifs) or by USB. because of the ftp server mode
> firmware, I must keep it formatted as a vfat filesystem.
>
> I have copied my music files on it using the ftp mode.  Using the same
> ftp mode, I can also retrieve my music files without problem, and
> when I list them, they have the exact names that they had on my linux
> ext3 partition.
>
> When I connected this disk via USB, now relying on the vfat module
> of linux, there were some directories that I could not reread.  The
> common factor of these directories names is that they end with one or
> more dots, e.g.
>
> 	Simon_&_Garfunkel-Wednesday_Morning,_3_a.m.
>
> If I issue the `ls' or `find' command, I get this strange message :
>
> find: ./Simon_&_Garfunkel-Wednesday_Morning,_3_a.m.: No such file or directory
>
> Adding printk's in `fat_search_long' revealed that on this disk, the
> file/directory NAMES ENDING WITH DOTS ARE STORED WITH THEIR TRAILING DOTS.
>
> Here is a patch squetch that make accessing my
>  Simon_&_Garfunkel-Wednesday_Morning,_3_a.m. directory possible, but I
> don't know if storing long filenames ending with dot's should not also
> be fixed.

IIRC, Windows stripped the trailing ".". That filename can be read/used on
Windows?

If it can be read, I think we should consider to remove
vfat_striptail_len() (at least for lookup path), more investigation
would be needed though.

Thanks.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: [PATCH RFC] vfat and Simon_&_Garfunkel-Wednesday_Morning,_3_a.m.

[Philippe De Muyter]

Hi Ogawa,

On Tue, Sep 29, 2009 at 07:05:27PM +0900, OGAWA Hirofumi wrote:
> Philippe De Muyter <phdm@macqel.be> writes:
> 
> > I have an IOMEGA home network hard disk that I can connect either by
> > ethernet (ftp or cifs) or by USB. Because of the ftp server mode
> > firmware, I must keep it formatted as a vfat filesystem.
> >
> > I have copied my music files on it using the ftp mode.  Using the same
> > ftp mode, I can also retrieve my music files without problem, and
> > when I list them, they have the exact names that they had on my linux
> > ext3 partition.
> >
> > When I connected this disk via USB, now relying on the vfat module
> > of linux, there were some directories that I could not reread.  The
> > common factor of these directories names is that they end with one or
> > more dots, e.g.
> >
> > 	Simon_&_Garfunkel-Wednesday_Morning,_3_a.m.
> >
> > If I issue the `ls' or `find' command, I get this strange message :
> >
> > find: ./Simon_&_Garfunkel-Wednesday_Morning,_3_a.m.: No such file or directory
> >
> > Adding printk's in `fat_search_long' revealed that on this disk, the
> > file/directory NAMES ENDING WITH DOTS ARE STORED WITH THEIR TRAILING DOTS.
> >
> > Here is a patch sketch that makes accessing my
> >  Simon_&_Garfunkel-Wednesday_Morning,_3_a.m. directory possible, but I
> > don't know if storing long filenames ending with dot's should not also
> > be fixed.
> 
> IIRC, Windows stripped the trailing ".". That filename can be read/used on
> Windows?

Sorry I don't use MS-Windows.  I'll try to find someone who does.

But, risking repeating myself, the firmware of the IOMEGA disk (via
the ftp interface) presents the filenames with the trailing dots.

> If it can be read, I think we should consider to remove
> vfat_striptail_len() (at least for lookup path), more investigation
> would be needed though.

That's what my patch does actually.  Maybe it should depend of the length
of the filename, though.

Thanks

Philippe

Re: [PATCH RFC] vfat and Simon_&_Garfunkel-Wednesday_Morning,_3_a.m.

[Philippe De Muyter]

Hi Ogawa,
On Tue, Sep 29, 2009 at 12:25:59PM +0200, I wrote:
> Hi Ogawa,
> 
> On Tue, Sep 29, 2009 at 07:05:27PM +0900, OGAWA Hirofumi wrote:
> > Philippe De Muyter <phdm@macqel.be> writes:
> > 
> > > I have an IOMEGA home network hard disk that I can connect either by
> > > ethernet (ftp or cifs) or by USB. Because of the ftp server mode
> > > firmware, I must keep it formatted as a vfat filesystem.
> > >
> > > I have copied my music files on it using the ftp mode.  Using the same
> > > ftp mode, I can also retrieve my music files without problem, and
> > > when I list them, they have the exact names that they had on my linux
> > > ext3 partition.
> > >
> > > When I connected this disk via USB, now relying on the vfat module
> > > of linux, there were some directories that I could not reread.  The
> > > common factor of these directories names is that they end with one or
> > > more dots, e.g.
> > >
> > > 	Simon_&_Garfunkel-Wednesday_Morning,_3_a.m.
> > >
> > > If I issue the `ls' or `find' command, I get this strange message :
> > >
> > > find: ./Simon_&_Garfunkel-Wednesday_Morning,_3_a.m.: No such file or directory
> > >
> > > Adding printk's in `fat_search_long' revealed that on this disk, the
> > > file/directory NAMES ENDING WITH DOTS ARE STORED WITH THEIR TRAILING DOTS.
> > >
> > > Here is a patch sketch that makes accessing my
> > >  Simon_&_Garfunkel-Wednesday_Morning,_3_a.m. directory possible, but I
> > > don't know if storing long filenames ending with dot's should not also
> > > be fixed.
> > 
> > IIRC, Windows stripped the trailing ".". That filename can be read/used on
> > Windows?
> 
> Sorry I don't use MS-Windows.  I'll try to find someone who does.

MS-Windows (XP SP3) lists correctly the names with their trailing dots.

Philippe

Re: [PATCH RFC] vfat and Simon_&_Garfunkel-Wednesday_Morning,_3_a.m.

[OGAWA Hirofumi]

Philippe De Muyter <phdm@macqel.be> writes:

>> > IIRC, Windows stripped the trailing ".". That filename can be read/used on
>> > Windows?
>> 
>> Sorry I don't use MS-Windows.  I'll try to find someone who does.
>
> MS-Windows (XP SP3) lists correctly the names with their trailing dots.

Ok. Is it meaning you could read the file correctly? I guess so, and
I'll review deeply about dcache issues for it.

Thanks.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: [PATCH RFC] vfat and Simon_&_Garfunkel-Wednesday_Morning,_3_a.m.

[Philippe De Muyter]

On Wed, Sep 30, 2009 at 08:02:01PM +0900, OGAWA Hirofumi wrote:
> Philippe De Muyter <phdm@macqel.be> writes:
> 
> >> > IIRC, Windows stripped the trailing ".". That filename can be read/used on
> >> > Windows?
> >> 
> >> Sorry I don't use MS-Windows.  I'll try to find someone who does.
> >
> > MS-Windows (XP SP3) lists correctly the names with their trailing dots.
> 
> Ok. Is it meaning you could read the file correctly? I guess so, and
> I'll review deeply about dcache issues for it.

Sorry. I did not test enough yesterday. It was late  :/

on MS-Windows XP SP#, the files and directories are listed with their
real name, including the trailing dots, but if one tries to open such a
file or go into such a directory, that fails with an error message.

With a "123456789." file :
Cannot find the E:\PUBLIC\trailing_dots\123456789. file.
Do you want to create a new file?
		Yes		No		Cancel

With a "directoryname." directory :
E\PUBLIC\trailing_dots\directoryname. refers to a location that is unavailable.
It could be on a hard drive on this computer, or on a network. Check to make
sure that the disk is properly inserted, or that you are connected to the
Internet or your network, and then try again.  If it still cannot be located,
the information might have been moved to a different location.
				OK

I don't think we want linux to remain compatible with this bug.  So perhaps
not removing the trailing dots for a lookup is all what is needed.

Best regards

Philippe

Re: [PATCH RFC] vfat and Simon_&_Garfunkel-Wednesday_Morning,_3_a.m.

[OGAWA Hirofumi]

Philippe De Muyter <phdm@macqel.be> writes:

> Sorry. I did not test enough yesterday. It was late  :/
>
> on MS-Windows XP SP#, the files and directories are listed with their
> real name, including the trailing dots, but if one tries to open such a
> file or go into such a directory, that fails with an error message.
>
> With a "123456789." file :
> Cannot find the E:\PUBLIC\trailing_dots\123456789. file.
> Do you want to create a new file?
> 		Yes		No		Cancel
>
> With a "directoryname." directory :
> E\PUBLIC\trailing_dots\directoryname. refers to a location that is unavailable.
> It could be on a hard drive on this computer, or on a network. Check to make
> sure that the disk is properly inserted, or that you are connected to the
> Internet or your network, and then try again.  If it still cannot be located,
> the information might have been moved to a different location.
> 				OK
>
> I don't think we want linux to remain compatible with this bug.  So perhaps
> not removing the trailing dots for a lookup is all what is needed.

I think to make that filename readable is not crazy, however it would be
the part of design.

And I found one issue for now, fs has to check existant file to make new
file. But if lookup and creation was using different name, the check can
not be done with that patch correctly.

Thanks.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

[PATCH vfat] allow retrieving entries with trailing dots

[Philippe De Muyter]

This fixes accessing vfat entries with trailing dots created by an external
vfat driver (like the one in IOMEGA home network hard drives)

Philippe

--

Some vfat-formatted network disks that are also usb disk do not discard
trailing dots when creating files or directories via ftp.
When connected via usb to a linux machine, that leads to this problem :
if one issues the `ls' or `find' command, one gets this message :

find: ./Simon_&_Garfunkel-Wednesday_Morning,_3_a.m.: No such file or directory

Fix that by first trying to retrieve the entry with the full name, and only if
that fails and there are trailing dots in the searched name, try then to find
the truncated name.

Signed-off-by: Philippe De Muyter <phdm@macqel.be>

--- a/fs/fat/namei_vfat.c	2009-09-10 00:13:59.000000000 +0200
+++ b/fs/fat/namei_vfat.c	2010-02-08 02:28:37.010096903 +0100
@@ -702,9 +702,22 @@
 static int vfat_find(struct inode *dir, struct qstr *qname,
 		     struct fat_slot_info *sinfo)
 {
-	unsigned int len = vfat_striptail_len(qname);
+	int err;
+	unsigned int len;
+
+	/* Some combined ethernet + usb external hard drive do not
+	 * remove the trailing dots when creating entries in ethernet mode.
+	 * (e.g. Iomega Home Network Hard Drive)
+	 * Make accessing those entries possible.
+	 */
+	err = fat_search_long(dir, qname->name, qname->len, sinfo);
+	if (!err)
+		return err;
+	len = vfat_striptail_len(qname);
 	if (len == 0)
 		return -ENOENT;
+	if (len == qname->len)
+		return err;
 	return fat_search_long(dir, qname->name, len, sinfo);
 }