[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.61.0609170023500.24270@yvahk01.tjqt.qr>
Date: Sun, 17 Sep 2006 00:26:22 +0200 (MEST)
From: Jan Engelhardt <jengelh@...ux01.gwdg.de>
To: Josef Sipek <jsipek@....cs.sunysb.edu>
cc: linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
hch@...radead.org, akpm@...l.org, viro@....linux.org.uk
Subject: Re: [PATCH 05/22][RFC] Unionfs: Copyup Functionality
>> >> Is BUG the right thing, what do others think? (Using WARN, and set err to
>> >> something useful?)
>> >
>> >Well, it is definitely a condition which Unionfs doesn't expect - if it
>> >doesn't know about the type, how could it copy it up?
>>
>> Other filesystems don't seem to BUG either (at least I have not run into
>> that yet) when - for whatever reasons - the statdata of a dentry is
>> fubared. `ls` just displays it then, like
>>
>> ?-w---Sr-T 1 root root 4294967295 date fubared_file
>
>I was thinking about this, and the difference between "other filesystems"
>and unionfs in this case is that the example above is just stat. During
>copyup, unionfs has to copy the file to another filesystem. How is it
>supposed to do that when it doesn't understand what the file is?
>
>Sure, when unionfs does stat, fubared statdata is fine, but during
>copyup...bad things could potentially happen.
>
>Any suggestions how to copyup an unknown file type?
Return some error value if possible. -EIO, banners, big printk()s,
anything. Tell the user the filesytem on some branch is hosed - or
too advanced to be understood by unionfs. (There seems to be a
variety of file types in other UNIXes according to `man 2 stat`,
such as doors, etc.)
Jan Engelhardt
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists