zfs discuss - Jun 2006 - Why is "+" not allowed in a ZFS file system name ?

I accidentally tried to create a ZFS file system called lost+found[1] 
and zfs(1) told me that + was an invalid char for a filesystem name.

Why is that ?

[1] cd /export/projects (where that is a ufs file system)
     for i in * ; do
	zfs create cube/projects/$i
     done


-- 
Darren J Moffat

Simply because we erred on the side of caution.  The fewer metachacters,
the better.  It''s easy to change if there''s enough interest.

- Eric

On Mon, Jun 19, 2006 at 04:01:01PM +0100, Darren J Moffat
wrote:
> I accidentally tried to create a ZFS file system called lost+found[1] 
> and zfs(1) told me that + was an invalid char for a filesystem name.
> 
> Why is that ?
> 
> [1] cd /export/projects (where that is a ufs file system)
>     for i in * ; do
> 	zfs create cube/projects/$i
>     done
> 
> 
> -- 
> Darren J Moffat
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
--
Eric Schrock, Solaris Kernel Development       http://blogs.sun.com/eschrock

Eric Schrock wrote:
> Simply because we erred on the side of caution.  The fewer metachacters,
> the better.  It''s easy to change if there''s enough
interest.
Seems reasonable.

In my case it actually saved me having to remember to go and do zfs 
destroy cube/projects/lost+found :-) but I didn''t think it was a
feature
just for that so I asked.

I don''t see any real reason to change it. The only reason might be if 
people expect that ZFS data set names should always be their file system 
mount point minus the leading ''/'';

> - Eric
> 
> On Mon, Jun 19, 2006 at 04:01:01PM +0100, Darren J Moffat wrote:
>> I accidentally tried to create a ZFS file system called lost+found[1] 
>> and zfs(1) told me that + was an invalid char for a filesystem name.
>>
>> Why is that ?
>>
>> [1] cd /export/projects (where that is a ufs file system)
>>     for i in * ; do
>> 	zfs create cube/projects/$i
>>     done
>>
>>
>> -- 
>> Darren J Moffat
>> _______________________________________________
>> zfs-discuss mailing list
>> zfs-discuss at opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
> 
> --
> Eric Schrock, Solaris Kernel Development      
http://blogs.sun.com/eschrock

-- 
Darren J Moffat

On 6/19/06, Eric Schrock <eric.schrock at sun.com>
wrote:
> Simply because we erred on the side of caution.  The fewer metachacters,
> the better.  It''s easy to change if there''s enough
interest.
You may want to change that since many applications including KDE use
''''+'' to encode paths (replacing blanks or use it for
other purposes),
resulting in erratic failure of desktop functions.
And ''+'' is used very often elsewhere so more than one
application will fail.

Holger

>On 6/19/06, Eric Schrock <eric.schrock at sun.com> wrote:
>> Simply because we erred on the side of caution.  The fewer
metachacters,
>> the better.  It''s easy to change if there''s enough
interest.
>
>You may want to change that since many applications including KDE use
>''''+'' to encode paths (replacing blanks or use it
for other purposes),
>resulting in erratic failure of desktop functions.
>And ''+'' is used very often elsewhere so more than one
application will fail.
So you believe that "+" should be allowed in filesystem names?  (As
opposed
to filenames where there is no such restriction?)

Casper

Perhaps this discussion wasn''t quite clear.  ZFS supports all
characters (with the standard UNIX exceptions of null and forward slash) in
filenames.

It''s only the names of ZFS data structures, such as file systems,
pools, and snapshots, which are restricted.  For instance, @ is used as a
separator and hence cannot be part of a file system name without ambiguity.

Files and directories can be named without restrictions, so there''s
nothing to worry about.  :-)
 
 
This message posted from opensolaris.org

On 6/20/06, Casper.Dik at sun.com <Casper.Dik at sun.com>
wrote:
>
> >On 6/19/06, Eric Schrock <eric.schrock at sun.com> wrote:
> >> Simply because we erred on the side of caution.  The fewer
metachacters,
> >> the better.  It''s easy to change if there''s
enough interest.
> >
> >You may want to change that since many applications including KDE use
> >''''+'' to encode paths (replacing blanks or
use it for other purposes),
> >resulting in erratic failure of desktop functions.
> >And ''+'' is used very often elsewhere so more than one
application will fail.
>
> So you believe that "+" should be allowed in filesystem names? 
(As opposed
> to filenames where there is no such restriction?)
Ok... I misread this that file names are restricted that way. However
I still think all characters which are used by the urlencoding system
should be allowed, including "%" and "+". And please BAN the
usage of
white spaces (space, TAB, newline, cr).

Holger

>On 6/20/06, Casper.Dik at sun.com <Casper.Dik at sun.com> wrote:
>>
>> >On 6/19/06, Eric Schrock <eric.schrock at sun.com> wrote:
>> >> Simply because we erred on the side of caution.  The fewer
metachacters,
>> >> the better.  It''s easy to change if there''s
enough interest.
>> >
>> >You may want to change that since many applications including KDE
use
>> >''''+'' to encode paths (replacing blanks
or use it for other purposes),
>> >resulting in erratic failure of desktop functions.
>> >And ''+'' is used very often elsewhere so more than
one application will fail.
>>
>> So you believe that "+" should be allowed in filesystem
names?  (As opposed
>> to filenames where there is no such restriction?)
>
>Ok... I misread this that file names are restricted that way. However
>I still think all characters which are used by the urlencoding system
>should be allowed, including "%" and "+". And please BAN
the usage of
>white spaces (space, TAB, newline, cr).
I''m sure white space is banned (hope so, anyway) because of issues with
parsing /etc/mnttab by programs.

Casper

Holger Berger wrote:
> On 6/19/06, Eric Schrock <eric.schrock at sun.com> wrote:
>> Simply because we erred on the side of caution.  The fewer
metachacters,
>> the better.  It''s easy to change if there''s enough
interest.
> 
> You may want to change that since many applications including KDE use
> ''''+'' to encode paths (replacing blanks or use it
for other purposes),
> resulting in erratic failure of desktop functions.
> And ''+'' is used very often elsewhere so more than one
application will
> fail.
This doesn''t impact the mount point name or the names of files created 
with open(2) or directory names.  It only impacts the "device" name,
ie
the ZFS filesystem name used instead of things like /dev/md/dsk/d50.

So I don''t see how this could be a problem for KDE.

-- 
Darren J Moffat

On 6/20/06, Darren J Moffat <Darren.Moffat at sun.com>
wrote:
> Holger Berger wrote:
> > On 6/19/06, Eric Schrock <eric.schrock at sun.com> wrote:
> >> Simply because we erred on the side of caution.  The fewer
metachacters,
> >> the better.  It''s easy to change if there''s
enough interest.
> >
> > You may want to change that since many applications including KDE use
> > ''''+'' to encode paths (replacing blanks or
use it for other purposes),
> > resulting in erratic failure of desktop functions.
> > And ''+'' is used very often elsewhere so more than
one application will
> > fail.
>
> This doesn''t impact the mount point name or the names of files
created
> with open(2) or directory names.  It only impacts the "device"
name, ie
> the ZFS filesystem name used instead of things like /dev/md/dsk/d50.
>
> So I don''t see how this could be a problem for KDE.
OK
I still think it may be a good idea to allow all characters used by
urlencode as this allows the encoding of any characters by the calling
application on demand. Its not used yet but it may be useful in the
future.

Holger

# zpool create 500megpool /home/roland/tmp/500meg.dat
cannot create ''500megpool'': name must begin with a letter
pool name may have been omitted

huh?
ok - no problem if special characters aren`t allowed, but why _this_ weird
looking limitaton ?
 
 
This message posted from opensolaris.org

On 10-Jan-07, at 5:29 PM, roland wrote:
> # zpool create 500megpool /home/roland/tmp/500meg.dat
> cannot create ''500megpool'': name must begin with a letter
> pool name may have been omitted
>
> huh?
> ok - no problem if special characters aren`t allowed, but why  
> _this_ weird looking limitaton ?
>
Potential for confusion with numbers (esp since alphabetic units are  
often suffixed).

--T
>
> This message posted from opensolaris.org
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss