On 6/19/06, Eric Schrock <[EMAIL PROTECTED]> 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
On 6/20/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>On 6/19/06, Eric Schrock <[EMAIL PROTECTED]> 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 appl
On 6/20/06, Darren J Moffat <[EMAIL PROTECTED]> wrote:
Holger Berger wrote:
> On 6/19/06, Eric Schrock <[EMAIL PROTECTED]> wrote:
>> Simply because we erred on the side of caution. The fewer metachacters,
>> the better. It's easy to change if there's enough
On 8/10/06, Neil Perrin <[EMAIL PROTECTED]> wrote:
Myron Scott wrote:
> Is there any difference between fdatasync and fsync on ZFS?
-No. ZFS does not log data and meta data separately. rather
it logs essentially the system call records, eg writes, mkdir,
truncate, setattr, etc. So fdatasync and
On 12/29/06, Eric Schrock <[EMAIL PROTECTED]> wrote:
On Thu, Dec 28, 2006 at 04:07:57PM -0800, Jason Austin wrote:
> When messing around with zfs trying to break it, I creating a new pool
> using files on an existing zfs filesystem. It seem to work fine until
> I created a snapshot of the origin
On 12/29/06, Eric Schrock <[EMAIL PROTECTED]> wrote:
On Fri, Dec 29, 2006 at 01:48:17PM -0800, Jason Austin wrote:
> Which part is the bug? The crash or allowing pools of files that are on a
zfs?
The crash. Disallowing files from a ZFS filesystem would solve part of
the problem, but one could
On 12/29/06, Eric Schrock <[EMAIL PROTECTED]> wrote:
On Fri, Dec 29, 2006 at 11:23:30PM +0100, Holger Berger wrote:
>
> So the goal is to allow infinite nesting?
>
That would be my guess, based on the fact that disallowing the opposite
is effectively impossible.
I guess it may
On 12/30/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>However, it gets interesting when SVID3 comes into play:
>
>
> The link(BA_OS) and unlink(BA_OS) descriptions in SVID3 both specify that
> a process with appropriate privileges is allowed to operate on a
>directory.
> We have claim
