Re: E2fsprogs git tree
Theodore Tso wrote: What version of git are you using? Make sure you are using something which is at least git 1.5.x. Thanks for your answer. I'm using an older version of git, 1.4.4.4. I've never got any problem with it to download a linux kernel tree using an http URL, but I will update it. The http walkers are *much* more inefficient. I did try out git-clone using the http URL's, and it works, but it's slow. The other possibility is that you have some kind of nasty http transparent proxy which is corrupting the http protocol stream. This is why the git transport is seriously the much, much, MUCH better alternative. Yes, we have an http proxy. No problem with it until now. I will use the git protocol now as you advise me. Thank you again, Valérie - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: E2fsprogs git tree
On Tue, Aug 07, 2007 at 12:39:56PM -0500, Jose R. Santos wrote: I get the same error as Valerie when using version 1.4.4.2. The same version worked a couple of weeks ago when using the http URL. I'd strongly advise that you use git 1.5.x and update to use a 1.5 style clone of the repository. It's much, MUCH, easier to use than git 1.4 - Ted - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/25] move handling of setuid/gid bits from VFS into individual setattr functions (RESEND)
On Wed, 8 Aug 2007 08:54:35 -0400 Jeff Layton [EMAIL PROTECTED] wrote: On Tue, 7 Aug 2007 17:15:01 -0700 Andrew Morton [EMAIL PROTECTED] wrote: On Mon, 6 Aug 2007 09:54:03 -0400 Jeff Layton [EMAIL PROTECTED] wrote: Is there any way in which we can prevent these problems? Say - rename something so that unconverted filesystems will reliably fail to compile? I suppose we could rename the .setattr inode operation to something else, but then we'll be stuck with it for at least a while. That seems sort of kludgey too... Sure. We're changing the required behaviour of .setattr. Changing its name is a fine and reasonably reliable way to communicate that fact. - leave existing filesystems alone, but add a new inode_operations.setattr_jeff, which the networked filesytems can implement, and teach core vfs to call setattr_jeff in preference to setattr? Something else? There's also the approach suggested by Miklos: Add a new inode flag that tells notify_change not to convert ATTR_KILL_S* flags into a mode change. Basically, allow filesystems to opt out of that behavior. I'd definitly pick that over a new inode op. That would also allow the default case be for the VFS to continue handling these flags. Everything would continue to work but filesystems that need to handle these flags differently would be able to do so. We should opt for whatever produces the best end state in the kernel tree. ie: if it takes more work and a larger patch to create a better result, let's go for the better result. We merge large patches all the time. We prefer to smash through, get it right whatever the transient cost. But quietly making out-of-tree filesystems less secure is a pretty high cost. I'm suspecting that adding more flags and some code to test them purely to minimise the size of the patch and to retain compatibility with the old .setattr is not a good tradeoff, given that we'd carry the flags and tests for evermore. So I'd suggest s/setattr/something_else/g. - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [fuse-devel] [PATCH 00/25] move handling of setuid/gid bits from VFS into individual setattr functions (RESEND)
On Aug 8 2007 09:48, Andrew Morton wrote: On Mon, 6 Aug 2007 09:54:03 -0400 Jeff Layton [EMAIL PROTECTED] wrote: Is there any way in which we can prevent these problems? Say - rename something so that unconverted filesystems will reliably fail to compile? I suppose we could rename the .setattr inode operation to something else, but then we'll be stuck with it for at least a while. That seems sort of kludgey too... Sure. We're changing the required behaviour of .setattr. Changing its name is a fine and reasonably reliable way to communicate that fact. Maybe -chattr/-chgattr? Jan -- - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
