> Calling pathconf with a symlink is not defined.
The Austin draft requires pathconf to follow symlinks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Al Viro writes:
> Andreas Dilger wrote:
> > Actually, this is wrong. The ext2 inode limit is 2^32 512-byte sectors,
> > not 2^32 blocksize blocks. Yes this is a wart and Ted wants to fix it, as
>
> ??? Where? Oh, wait... ->i_blocks? I'ld rather refuse to grow past 2^32 -
> sparse files can legi
On Mon, 8 Jan 2001, Andreas Dilger wrote:
> Actually, this is wrong. The ext2 inode limit is 2^32 512-byte sectors,
> not 2^32 blocksize blocks. Yes this is a wart and Ted wants to fix it, as
??? Where? Oh, wait... ->i_blocks? I'ld rather refuse to grow past 2^32 -
sparse files can legitimat
Al Viro writes:
> No, it doesn't. s/$/while(bh != head);/, indeed. Sorry about that -
> cut-and-waste when I did rediff to 2.4.0. Corrected patch follows:
>
> diff -urN S0-AC4/fs/ext2/super.c S0-AC4-fixes/fs/ext2/super.c
> --- S0-AC4/fs/ext2/super.cMon Jan 8 08:46:18 2001
> +++ S0-AC4-fixes/
On Mon, 8 Jan 2001, Marc Lehmann wrote:
> On Mon, Jan 08, 2001 at 01:33:50PM -0500, Alexander Viro <[EMAIL PROTECTED]> wrote:
> > And prefix would be what? "/"? Besides, I said that you don't have
> > read permissions on /foo, not search ones.
>
> You do not need read permissions on /foo to ma
On Mon, Jan 08, 2001 at 01:33:50PM -0500, Alexander Viro <[EMAIL PROTECTED]> wrote:
> And prefix would be what? "/"? Besides, I said that you don't have
> read permissions on /foo, not search ones.
You do not need read permissions on /foo to make pathconf on it. This
makes sense: you are not read
On Mon, Jan 08, 2001 at 01:33:50PM -0500, Alexander Viro wrote:
>
> On Mon, 8 Jan 2001, Stefan Traby wrote:
>
> > On Mon, Jan 08, 2001 at 01:22:49PM -0500, Alexander Viro wrote:
> >
> > > Here's another one: suppose that /foo is a mountpoint and you have
> > > no read permissions on it. Try to
On Mon, 8 Jan 2001, Stefan Traby wrote:
> On Mon, Jan 08, 2001 at 01:22:49PM -0500, Alexander Viro wrote:
>
> > Here's another one: suppose that /foo is a mountpoint and you have
> > no read permissions on it. Try to open the thing...
>
> I would return EACCESS.
> [EACCES]
> Search
On Mon, Jan 08, 2001 at 01:22:49PM -0500, Alexander Viro wrote:
> Here's another one: suppose that /foo is a mountpoint and you have
> no read permissions on it. Try to open the thing...
I would return EACCESS.
[EACCES]
Search permission is denied for a component of the path prefix.
On Mon, 8 Jan 2001, Stefan Traby wrote:
> Calling pathconf with a symlink is not defined. I suggest
> an implementation of "yankee doodle" for that case.
> Anyway the broken SuS standard wants that pathconf follow symlinks.
> Or how do you interpret this:
>
> [ELOOP]
>Too many sym
On Mon, Jan 08, 2001 at 01:05:49PM -0500, Alexander Viro wrote:
>
>
> On Mon, 8 Jan 2001, Stefan Traby wrote:
>
> > On Mon, Jan 08, 2001 at 04:01:10PM +, Alan Cox wrote:
> > > > I prefer SuS fpathconf(), pathconf() is just a wrapper to fpathconf();
> > >
> > > You can't implement it that w
On Mon, 8 Jan 2001, Stefan Traby wrote:
> On Mon, Jan 08, 2001 at 04:01:10PM +, Alan Cox wrote:
> > > I prefer SuS fpathconf(), pathconf() is just a wrapper to fpathconf();
> >
> > You can't implement it that way in the corner cases.
>
> I reread SuSv2 again and didn't found corner cases.
On Mon, Jan 08, 2001 at 04:01:10PM +, Alan Cox wrote:
> > I prefer SuS fpathconf(), pathconf() is just a wrapper to fpathconf();
>
> You can't implement it that way in the corner cases.
I reread SuSv2 again and didn't found corner cases.
Do you mean FIFO/pipe stuff ? I can't see the problem
> if (pos + count > inode->i_sb->s_maxbytes)
> {
> count = inode->i_sb->s_maxbytes - count;
> goto out;
> }
>
> looks funny - goto out means that new (and rather meaningless) value of
> count goes to hell. Shouldn't we remove that line and
On Mon, 8 Jan 2001, Chris Mason wrote:
>
> On Monday, January 08, 2001 10:47:41 AM -0500 Alexander Viro
> <[EMAIL PROTECTED]> wrote:
> > + do {
> > + if (buffer_mapped(bh)) {
> > + bh->b_end_io = end_buffer_io_async;
> > + atomic_inc(&bh->b_count
> I reread SuSv2 again and didn't found corner cases.
> Do you mean FIFO/pipe stuff ? I can't see the problem in this area.
>
> In which case is an emulation of pathconf by fpathconf impossible ?
use all your file descriptors up. Now try
-
To unsubscribe from this list: send the line "unsubscri
On Monday, January 08, 2001 10:47:41 AM -0500 Alexander Viro
<[EMAIL PROTECTED]> wrote:
> + do {
> + if (buffer_mapped(bh)) {
> + bh->b_end_io = end_buffer_io_async;
> + atomic_inc(&bh->b_count);
> + set_bit(BH_Uptodate,
> I prefer SuS fpathconf(), pathconf() is just a wrapper to fpathconf();
You can't implement it that way in the corner cases.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
On Mon, Jan 08, 2001 at 02:40:45PM +, Alan Cox wrote:
> > > Why not start to fix this problem outside the funny switch/case in glibc ?
> > > The filesystem itself should able to handle this.
> >
> > Sigh... And the API would be?
>
> In SuS its pathconf()
I prefer SuS fpathconf(), pathconf()
On Mon, 8 Jan 2001, Chris Mason wrote:
>
>
> On Monday, January 08, 2001 09:02:46 AM -0500 Alexander Viro
> <[EMAIL PROTECTED]> wrote:
>
> > Alan, consider applying the patch below.
> > Contents:
> [snip]
> > + do {
> > + if (buffer_mapped(bh)) {
> > + bh->b_end
On Monday, January 08, 2001 09:02:46 AM -0500 Alexander Viro
<[EMAIL PROTECTED]> wrote:
> Alan, consider applying the patch below.
> Contents:
[snip]
> + do {
> + if (buffer_mapped(bh)) {
> + bh->b_end_io = end_buffer_io_async;
> + atomic_
On Mon, 8 Jan 2001, Alan Cox wrote:
> > Which happens to be remarkably ugly. And it will not get better tomoorow...
>
> Its really only ugly in one way which is that you pass an int for the item
> rather than having a struct of all the data
You know as well as I do that as soon as we add it g
> Which happens to be remarkably ugly. And it will not get better tomoorow...
Its really only ugly in one way which is that you pass an int for the item
rather than having a struct of all the data
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
On Mon, 8 Jan 2001, Alan Cox wrote:
> > > Why not start to fix this problem outside the funny switch/case in glibc ?
> > > The filesystem itself should able to handle this.
> >
> > Sigh... And the API would be?
>
> In SuS its pathconf()
Which happens to be remarkably ugly. And it will not ge
> > Why not start to fix this problem outside the funny switch/case in glibc ?
> > The filesystem itself should able to handle this.
>
> Sigh... And the API would be?
In SuS its pathconf()
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMA
On Mon, 8 Jan 2001, Stefan Traby wrote:
> Because I have no knowledge on this I suggest that you and Ulrich fight
> together on a more flexible solution than the current one. I guess
> that Linus would accept this without thinking too much about it.
Unfortunately, Ulrich's taste was incompatib
Alan, consider applying the patch below.
Contents:
* recovery from failing get_block() in __block_write_full_page()
and __block_prepare_write().
* handling of partially mapped pages in generic_file_write().
* use of ->s_maxbytes in default_llseek().
* crapectomy in
On Mon, Jan 08, 2001 at 08:35:10AM -0500, Alexander Viro wrote:
> On Mon, 8 Jan 2001, Stefan Traby wrote:
> > Try 'getconf LINK_MAX /ramfs'.
> > While the result (127) is in some way SuS/POSIXLY_CORRECT,
> > it's not the truth.
> >
> > Why not start to fix this problem outside the funny switch/ca
[EMAIL PROTECTED] said:
> I put it into generic_file_write. That covers most fs's it seems. The
> jffs guys are going to switch to generic_file_write soon
It's in CVS already. For 2.4, 'soon' == 'when Linus is ready to start taking
patches'
If you want it for 2.4-ac I can provide a patch whi
On Mon, 8 Jan 2001, Stefan Traby wrote:
> On Mon, Jan 08, 2001 at 12:26:17PM +, Alan Cox wrote:
>
> > I can put all that in the VFS so I did (right now the ext2 size calculator is
> > wrong but thats proof of concept detail). Just need to shift if over from
> > ext2/file.c
>
> Try 'getcon
On Mon, Jan 08, 2001 at 12:26:17PM +, Alan Cox wrote:
> I can put all that in the VFS so I did (right now the ext2 size calculator is
> wrong but thats proof of concept detail). Just need to shift if over from
> ext2/file.c
Try 'getconf LINK_MAX /ramfs'.
While the result (127) is in some way
> Umm... Details, please? Are you talking about 2^32 or about fs layout limits?
> The former may very well belong to VFS - no arguments here. The latter...
> And yes, fs layout limits are visible - for ext2 they can be as low as 2^24
> blocks.
The SuS rules require write checks
resource limit
On Mon, 8 Jan 2001, Alan Cox wrote:
> > > I put it into generic_file_write. That covers most fs's it seems. The jffs
> > > guys are going to switch to generic_file_write soon and the other fs's
> > > that dont are wacko ones I dont care about ;)
> >
> > Alan, we have to deal with get_block()
> > I put it into generic_file_write. That covers most fs's it seems. The jffs
> > guys are going to switch to generic_file_write soon and the other fs's
> > that dont are wacko ones I dont care about ;)
>
> Alan, we have to deal with get_block() failures anyway. -ENOSPC, -EDQUOT,
> not to ment
On Mon, 8 Jan 2001, Alan Cox wrote:
> > Alan, it doesn't work that way. Maximal size depends on the type of object,
> > for one thing. Moreover, it's not always a multiple of page size, so you
>
> Its a multiple of page size for all fs's we have but I did it in terms of
> bytes anyway
1Kb-blo
> There is code to support this in 2.4.0-ac4 -- initially I didn't like
> the way Alan had done things (I was think -EFBIG should be used only
> for LFS violations) but after some thought has decided that what he
> has makes a lot of sense.
Its based on the docs I have + a test program for the no
> Alan, it doesn't work that way. Maximal size depends on the type of object,
> for one thing. Moreover, it's not always a multiple of page size, so you
Its a multiple of page size for all fs's we have but I did it in terms of
bytes anyway
> still need foo_get_block() to be aware of the problem
On Mon, 8 Jan 2001, Chris Wedgwood wrote:
> On Mon, Jan 08, 2001 at 02:56:10AM -0500, Alexander Viro wrote:
>
> Plenty. ext2, for one - e.g. with 4Kb blocks you have limit
> at 0x4010040c000 for files and 0x1 for directories. With
> 1Kb blocks the limit for files is 0x404
On Sun, 7 Jan 2001, Chris Wedgwood wrote:
> On Sat, Jan 06, 2001 at 03:35:32PM +, Alan Cox wrote:
>
> BTW Al: We have another general vfs/fs problem to handle - which
> is exceeding max file sizes on limited file systems. Pretty much
> nobody is getting it right. Ext2 can be tr
On Sat, 6 Jan 2001, Alan Cox wrote:
> > > > Add UnlockPage(page) at the end of ramfs_writepage().
> > > Shit. You are quite fast. Works.
> >
> > Sure, especially considering the fact that patch was sent to
> > Linus about a month ago (several times, actually)... ;-/
>
> Its in all the -ac
Alan Cox <[EMAIL PROTECTED]> writes:
> > Putting the LFS checks, & max filesize checks into the VFS sounds
> > right for 2.4.x because it fixes lots of filesystems, with just a
> > couple of lines of code.
>
> Rather more than that, and it only fixes those using generic_file_*
True. But it is
> .. or we can check 'up one level' by adding another method to struct
> file_operations perhaps (gross?).
Not feasible. SOme work has to be done by the fs in certain cases. I can cover
the majority of them tho
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
> THis means we limit all NFS file sizes to 32-bits unless we have
> NFSv3? (I assume v3 is where the 64-bit file sizes comes from? or
> does it predate that?)
NFSv2 has a 32bit file offset. Thus the largest file on NFSv2 you want to
touch is 2Gig.
Alan
-
To unsubscribe from this list: send th
> Putting the LFS checks, & max filesize checks into the VFS sounds
> right for 2.4.x because it fixes lots of filesystems, with just a
> couple of lines of code.
Rather more than that, and it only fixes those using generic_file_*
-
To unsubscribe from this list: send the line "unsubscribe linu
Chris Wedgwood <[EMAIL PROTECTED]> writes:
> On Sat, Jan 06, 2001 at 03:58:20PM +, Alan Cox wrote:
>
> Ext2 handles large files almost properly. (properly on 2.2 +
> patches) NFSv3 handles large files but might be missing the
> O_LARGEFILE check. I believe reiserfs went to at le
> Which filesystems have limits other than 2^31 bytes?
Ext2 handles large files almost properly. (properly on 2.2 + patches)
NFSv3 handles large files but might be missing the O_LARGEFILE check.
I believe reiserfs went to at least 4Gig.
> O_LARGEFILE at present (well, their is perhaps good reaso
> > > Add UnlockPage(page) at the end of ramfs_writepage().
> > Shit. You are quite fast. Works.
>
> Sure, especially considering the fact that patch was sent to
> Linus about a month ago (several times, actually)... ;-/
Its in all the -ac trees 8)
BTW Al: We have another general vfs/fs p
On Sat, 6 Jan 2001, Stefan Traby wrote:
> On Fri, Jan 05, 2001 at 11:52:31PM -0500, Alexander Viro wrote:
> > On Sat, 6 Jan 2001, Stefan Traby wrote:
> >
> > > Then I tried to unlink the file by running rm lfs.file log.
> > >
> > > The rm process (and an ls process that I started after that)
On Fri, Jan 05, 2001 at 11:52:31PM -0500, Alexander Viro wrote:
> On Sat, 6 Jan 2001, Stefan Traby wrote:
>
> > Then I tried to unlink the file by running rm lfs.file log.
> >
> > The rm process (and an ls process that I started after that)
> > are now in "D" state...
> >
> > root 2934 0.
On Sat, 6 Jan 2001, Stefan Traby wrote:
> Then I tried to unlink the file by running rm lfs.file log.
>
> The rm process (and an ls process that I started after that)
> are now in "D" state...
>
> root 2934 0.0 0.2 1292 452 pts/5D05:38 0:00 ls /ramfs
> root 2952 0.0
Hi !
I create a sparse file on ramfs (by writing 5 bytes at offset 3GB):
0.000269 open("./lfs.file", O_RDWR|O_CREAT|O_TRUNC|O_LARGEFILE, 0600) = 3
0.000214 _llseek(3, 18446744072635809792, [3221225472], SEEK_SET) = 0
0.000159 write(3, "hallo", 5) = 5
51 matches
Mail list logo
