From: Anton Altaparmakov <anton@tuxera.com>
To: David Howells <dhowells@redhat.com>
Cc: Jann Horn <jannh@google.com>, Al Viro <viro@zeniv.linux.org.uk>,
Linux API <linux-api@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 34/38] vfs: syscall: Add fsinfo() to query filesystem information [ver #10]
Date: Sat, 28 Jul 2018 00:14:14 +0000 [thread overview]
Message-ID: <7C807D58-6B8C-400F-AF67-CD2F38BC0AE4@tuxera.com> (raw)
In-Reply-To: <21395.1532735340@warthog.procyon.org.uk>
Hi David,
> On 28 Jul 2018, at 00:49, David Howells <dhowells@redhat.com> wrote:
> Jann Horn <jannh@google.com> wrote:
>>> +static int fsinfo_generic_name_encoding(struct dentry *dentry, char *buf)
>>> +{
>>> + static const char encoding[] = "utf8";
>>> +
>>> + if (buf)
>>> + memcpy(buf, encoding, sizeof(encoding) - 1);
>>> + return sizeof(encoding) - 1;
>>> +}
>>
>> Is this meant to be "encoding to be used by userspace" or "encoding of
>> on-disk filenames"?
>
> The latter.
>
>> Are there any plans to create filesystems that behave differently?
>
> isofs, fat, ntfs, cifs for example.
>
>> If the latter: This is wrong for e.g. a vfat mount that uses a codepage,
>> right? Should the default in that case not be "I don't know"?
>
> Quite possibly. Note that it could also be what you're interpreting it as
> because the codepage got overridden by a mount parameter rather than what's on
> the disk (assuming the medium actually records this).
No, nothing like that is recorded on disk. That would have been way too helpful! (-; The only place Windows records such information is, you may have guessed this: in the registry which of course is local to the computer and unrelated to what removable media is attached...
> One thing I'm confused about is that fat has both a codepage and a charset and
> I'm not sure of the difference.
Oh that is quite simple. (-:
The codepage is what is used to translate from/to the on-disk DOS 8.3 style names into the kernel's Unicode character representation. The correct codepage for a particular volume is not stored on disk so it can lead to all sorts of fun if you for example create some names on for example a Japanese Windows on a FAT formatted USB stick and then plug that into a US or European Windows where the default code pages are completely different - all your filenames will appear totally corrupt. (Note this ONLY affects 8.3 style/DOS/short names or whatever you want to call them.)
The charset on the other hand is what is used to convert strings coming in from/going out to userspace into the kernel's Unicode character representation.
The one nice thing about VFAT (and there aren't many nice things about it!) is that for long names (i.e. not the 8.3 style/DOS/short names), it actually stores on-disk little-endian UTF-16 (since Windows 2000, before that it used little endian UCS-2 - the change was needed to support things like Emojis and some languages that go outside the UCS-2 range of fixed 16-bit unicode).
Hope this clears that up.
Best regards,
Anton
> David
--
Anton Altaparmakov <anton at tuxera.com> (replace at with @)
Lead in File System Development, Tuxera Inc., http://www.tuxera.com/
Linux NTFS maintainer
next prev parent reply other threads:[~2018-07-28 0:14 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-27 17:31 [PATCH 00/38] VFS: Introduce filesystem context [ver #10] David Howells
2018-07-27 17:31 ` [PATCH 01/38] vfs: syscall: Add open_tree(2) to reference or clone a mount " David Howells
2018-07-27 17:31 ` [PATCH 02/38] vfs: syscall: Add move_mount(2) to move mounts around " David Howells
2018-07-27 17:34 ` [PATCH 26/38] vfs: syscall: Add fsopen() to prepare for superblock creation " David Howells
2018-07-27 17:34 ` [PATCH 29/38] vfs: syscall: Add fsconfig() for configuring and managing a context " David Howells
2018-07-27 19:42 ` Andy Lutomirski
2018-07-27 21:51 ` David Howells
2018-07-27 21:57 ` Andy Lutomirski
2018-07-27 22:27 ` David Howells
2018-07-27 22:32 ` Jann Horn
2018-07-29 8:50 ` David Howells
2018-07-29 11:14 ` Jann Horn
2018-07-30 12:32 ` David Howells
2018-07-27 17:34 ` [PATCH 30/38] vfs: syscall: Add fsmount() to create a mount for a superblock " David Howells
2018-07-27 19:27 ` Andy Lutomirski
2018-07-27 19:43 ` Andy Lutomirski
2018-07-27 22:09 ` David Howells
2018-07-27 22:06 ` David Howells
2018-07-27 17:34 ` [PATCH 31/38] vfs: syscall: Add fspick() to select a superblock for reconfiguration " David Howells
2018-07-27 17:35 ` [PATCH 34/38] vfs: syscall: Add fsinfo() to query filesystem information " David Howells
2018-07-27 19:35 ` Andy Lutomirski
2018-07-27 22:12 ` David Howells
2018-07-27 23:14 ` Jann Horn
2018-07-27 23:49 ` David Howells
2018-07-28 0:14 ` Anton Altaparmakov [this message]
2018-07-27 23:51 ` David Howells
2018-07-27 23:58 ` Jann Horn
2018-07-28 0:08 ` David Howells
2018-07-30 14:48 ` David Howells
2018-07-31 4:16 ` Al Viro
2018-07-31 12:39 ` David Howells
2018-07-31 13:20 ` David Howells
2018-07-31 23:49 ` Darrick J. Wong
2018-08-01 1:07 ` David Howells
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=7C807D58-6B8C-400F-AF67-CD2F38BC0AE4@tuxera.com \
--to=anton@tuxera.com \
--cc=dhowells@redhat.com \
--cc=jannh@google.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/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;
as well as URLs for NNTP newsgroup(s).