public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: tridge@samba.org
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Michael B Allen <mba2000@ioplex.com>,
	sfrench@samba.org, linux-ntfs-dev@lists.sourceforge.net,
	samba-technical@lists.samba.org, aia21@cantab.net,
	hirofumi@mail.parknet.co.jp,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: FAT, NTFS, CIFS and DOS attributes
Date: Tue, 4 Jan 2005 11:39:31 +1100	[thread overview]
Message-ID: <16857.58819.311223.845400@samba.org> (raw)
In-Reply-To: <41D9E23A.4010608@zytor.com>

 > Right, it's the "design is broken so everything ends up in user.*". 
 > Now, I clearly dislike the StudlyCaps used here, but if it's already 
 > deployed it's probably too late to fix this :(

Samba4 is only deployed by a very few brave sites (such as my wifes
server) who all know that things might change in non-compatible
ways. Still, I'd want a slightly stronger reason than dislike of
studly caps to change it :-)

 > Does Samba have any way do deal with VFAT short names?

Samba doesn't take advantage of the fact that VFAT can store short
names directly in the filesystem, and instead deals with short names
completely in userspace using a hash based name mangling scheme. It
treats VFAT as just another unix filesystem. People who want to deploy
a serious Samba server tend to want journaling, ACLs etc, so VFAT
isn't a candidate.

I currently don't store short file names in xattrs for Samba4 as there
has just no advantage to doing so. Without a "open by xattr contents"
call that doesn't have to scan the entire directory it is much more
efficient to store the 8.3 names in user-space where we can look them
up more efficiently. The scheme we use is to store a cache of
8.3->longname mappings, and when we get a 8.3 name that isn't in cache
we fall back to a directory scan, re-forming the 8.3 name using a hash
for each directory entry.

I'm also much less concerned about 8.3 names these days than I was a
few years ago, as the number of applications that need them is rapidly
dropping. There are some obvious exceptions (such as the idiotic API calls
that cmd.exe uses to implement "del *.*"), but we have worked out ways
to cope with those in a reasonable manner.

Cheers, Tridge

  reply	other threads:[~2005-01-04  0:50 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-03 22:24 FAT, NTFS, CIFS and DOS attributes H. Peter Anvin
2005-01-03 23:26 ` Michael B Allen
2005-01-03 23:33   ` H. Peter Anvin
2005-01-03 23:48     ` Michael B Allen
2005-01-03 23:55       ` H. Peter Anvin
2005-01-04  0:18     ` tridge
2005-01-04  0:24       ` H. Peter Anvin
2005-01-04  0:39         ` tridge [this message]
2005-01-04  0:57           ` H. Peter Anvin
2005-01-04  1:12             ` tridge
2005-01-04  1:31         ` Nicholas Miell
2005-01-04  1:48           ` H. Peter Anvin
2005-01-04  2:05             ` Nicholas Miell
2005-01-04 22:24       ` [Linux-NTFS-Dev] " Szakacsits Szabolcs
2005-01-04  1:21   ` tridge
2005-01-04  1:30     ` H. Peter Anvin
2005-01-03 23:28 ` Nicholas Miell
2005-01-04  0:05 ` tridge
2005-01-04  0:30   ` H. Peter Anvin
2005-01-04  0:58     ` tridge
2005-01-04  1:14       ` H. Peter Anvin
2005-01-04  1:36         ` tridge
2005-01-04  1:50           ` H. Peter Anvin
2005-01-04  2:05             ` tridge
2005-01-04  2:09               ` H. Peter Anvin
2005-01-04  2:23               ` Kyle Moffett
2005-01-04  2:49                 ` tridge
2005-01-04  3:39                   ` Kyle Moffett
2005-01-04  3:56                     ` tridge
2005-01-04  4:50                       ` Kyle Moffett
2005-01-04  4:05     ` Michael B Allen
2005-01-04 10:34 ` Anton Altaparmakov
2005-01-04 11:08   ` Anton Altaparmakov
2005-01-04 22:18   ` Nicholas Miell
2005-01-04 23:04     ` Anton Altaparmakov
2005-01-05  0:48       ` Nicholas Miell
2005-01-05  1:12         ` Nicholas Miell

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=16857.58819.311223.845400@samba.org \
    --to=tridge@samba.org \
    --cc=aia21@cantab.net \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-ntfs-dev@lists.sourceforge.net \
    --cc=mba2000@ioplex.com \
    --cc=samba-technical@lists.samba.org \
    --cc=sfrench@samba.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox