All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philippe De Muyter <phdm@macqel.be>
To: linux-kernel@vger.kernel.org, hirofumi@mail.parknet.co.jp
Subject: [PATCH RFC] vfat and Simon_&_Garfunkel-Wednesday_Morning,_3_a.m.
Date: Fri, 25 Sep 2009 21:46:36 +0200	[thread overview]
Message-ID: <20090925194636.GA15700@frolo.macqel> (raw)
In-Reply-To: <20090323140005.GB25840@frolo.macqel>

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,

  reply	other threads:[~2009-09-25 19:46 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-19 18:11 [PATCH] parport netmos 9845 & 9855 1P4S fixes Philippe De Muyter
2009-03-23  8:50 ` Philippe De Muyter
2009-03-23 13:21   ` christian pellegrin
2009-03-23 13:52     ` Philippe De Muyter
2009-03-23 14:00   ` Philippe De Muyter
2009-09-25 19:46     ` Philippe De Muyter [this message]
2009-09-29 10:05       ` [PATCH RFC] vfat and Simon_&_Garfunkel-Wednesday_Morning,_3_a.m OGAWA Hirofumi
2009-09-29 10:25         ` Philippe De Muyter
2009-09-29 22:43           ` Philippe De Muyter
2009-09-30 11:02             ` OGAWA Hirofumi
2009-09-30 22:19               ` Philippe De Muyter
2009-10-01 10:42                 ` OGAWA Hirofumi
2010-02-08  9:39                   ` [PATCH vfat] allow retrieving entries with trailing dots Philippe De Muyter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090925194636.GA15700@frolo.macqel \
    --to=phdm@macqel.be \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.