On Fri, Oct 06, 2017 at 07:57:01AM -0700, Matthew Wilcox wrote: > On Fri, Oct 06, 2017 at 01:09:42PM +1100, Dave Chinner wrote: > > On Thu, Oct 05, 2017 at 12:16:19PM -0400, J. Bruce Fields wrote: > > > This kind of restriction sounds more like a permanent feature of the > > > filesystem--something you'd set at mkfs time. > > > > > > We already have filesystems with these kinds of restrictions, don't we? > > > > In general, no. Filename storage typically defined in the > > filesystem on-disk formats as an opaque string of bytes - the > > filesystem has no business parsing them to determine validity of the > > bytes. Think encrypted filenames and the like - control characters > > in the on-disk format are most definitely necessary and therefore > > must be legal. > > Umm. But filenames still can't have / or \0 in them, so your encryption > already has to avoid at least two special characters. Filesystems can have those characters on disk without any problems. Most filesytsems do not null terminate dirents on disk - instead they keep a dirent length on disk to determine the length of the entry. "Opaque" means null is a valid character, not an "end of string" delimiter. Keep in mind that "/" is an OS dependent special character - other OS use different directory delimiters so have a different set of "special characters". This reinforces the fact that it is not the filesystem's job to police what is stored on disk - the filesysetm is just a GIGO filename storage mechanism - you get out exactly what you put in... > I agree with your main point though; there is no advantage to doing this > in each individual filesystem. Yup, especially when we consider filesystems that get mounted and written by different OS and independent filesystem implementations.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
