Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #28134 > unrolled thread

Strange Behaviour in finding Size of a File

Back to article view | Back to comp.lang.c

Contents

  Strange Behaviour in finding Size of a File felix <ckpradip@gmail.com> - 2012-11-08 23:09 -0800
    Re: Strange Behaviour in finding Size of a File "Where's all the China Blue food?" <chine.bleu@yahoo.com> - 2012-11-08 23:26 -0800
    Re: Strange Behaviour in finding Size of a File James Kuyper <jameskuyper@verizon.net> - 2012-11-09 06:56 -0500
      Re: Strange Behaviour in finding Size of a File felix <ckpradip@gmail.com> - 2012-11-12 22:23 -0800
        Re: Strange Behaviour in finding Size of a File James Kuyper <jameskuyper@verizon.net> - 2012-11-13 07:27 -0500
          Re: Strange Behaviour in finding Size of a File felix <ckpradip@gmail.com> - 2012-11-19 01:52 -0800
            Re: Strange Behaviour in finding Size of a File James Kuyper <jameskuyper@verizon.net> - 2012-11-19 08:09 -0500
    Re: Strange Behaviour in finding Size of a File Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-09 08:24 -0500
      Re: Strange Behaviour in finding Size of a File Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-11-10 06:06 -0800
        Re: Strange Behaviour in finding Size of a File Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-10 15:12 +0000
          Re: Strange Behaviour in finding Size of a File Ian Collins <ian-news@hotmail.com> - 2012-11-11 08:40 +1300
            Re: Strange Behaviour in finding Size of a File Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-10 20:36 +0000
        Re: Strange Behaviour in finding Size of a File Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-10 10:13 -0500
    Re: Strange Behaviour in finding Size of a File John Gordon <gordon@panix.com> - 2012-11-09 15:16 +0000
      Re: Strange Behaviour in finding Size of a File Mark Bluemel <mark_bluemel@pobox.com> - 2012-11-09 15:56 +0000
      Re: Strange Behaviour in finding Size of a File James Kuyper <jameskuyper@verizon.net> - 2012-11-09 11:01 -0500
    Re: Strange Behaviour in finding Size of a File Greg Martin <greg@softsprocket.com> - 2012-11-09 08:59 -0800
    Re: Strange Behaviour in finding Size of a File Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2012-11-09 19:42 +0100
      Re: Strange Behaviour in finding Size of a File Keith Thompson <kst-u@mib.org> - 2012-11-09 11:29 -0800
        Re: Strange Behaviour in finding Size of a File Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2012-11-09 20:47 +0100
          Re: Strange Behaviour in finding Size of a File Keith Thompson <kst-u@mib.org> - 2012-11-09 12:33 -0800
            Re: Strange Behaviour in finding Size of a File Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2012-11-10 02:08 +0100
              Re: Strange Behaviour in finding Size of a File Philip Lantz <prl@canterey.us> - 2012-11-09 18:33 -0800
                Re: Strange Behaviour in finding Size of a File gazelle@shell.xmission.com (Kenny McCormack) - 2012-11-10 02:58 +0000
                  Re: Strange Behaviour in finding Size of a File Philip Lantz <prl@canterey.us> - 2012-11-09 23:29 -0800
                    Re: Strange Behaviour in finding Size of a File Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-11-10 06:09 -0800
              Re: Strange Behaviour in finding Size of a File Ian Collins <ian-news@hotmail.com> - 2012-11-10 17:46 +1300
                Re: Strange Behaviour in finding Size of a File James Kuyper <jameskuyper@verizon.net> - 2012-11-10 22:20 -0500
                Re: Strange Behaviour in finding Size of a File Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-11-12 14:01 +0200
              Re: Strange Behaviour in finding Size of a File gazelle@shell.xmission.com (Kenny McCormack) - 2012-11-10 22:01 +0000
            Re: Strange Behaviour in finding Size of a File James Kuyper <jameskuyper@verizon.net> - 2012-11-09 22:14 -0500
              Re: Strange Behaviour in finding Size of a File Keith Thompson <kst-u@mib.org> - 2012-11-09 19:24 -0800
                Re: Strange Behaviour in finding Size of a File James Kuyper <jameskuyper@verizon.net> - 2012-11-09 23:30 -0500
                Re: Strange Behaviour in finding Size of a File Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-10 08:32 -0500
                  Re: Strange Behaviour in finding Size of a File Ike Naar <ike@sverige.freeshell.org> - 2012-11-10 17:42 +0000
                    Re: Strange Behaviour in finding Size of a File Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-10 15:19 -0500
    Re: Strange Behaviour in finding Size of a File Keith Thompson <kst-u@mib.org> - 2012-11-09 11:34 -0800

Page 2 of 2 — ← Prev page 1 [2]

#28147

Alain Ketterlin <alain@dpt-info.u-strasbg.fr> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Alain Ketterlin <alain@dpt-info.u-strasbg.fr> writes:
>>> felix <ckpradip@gmail.com> writes:
>>>> if ( stat ( logFile, &results ) == 0 )
>>>
>>> Use ftell() instead (or lseek() at level 2).
>>
>> What makes you think that will yield better results,
>
> What makes you think it will not. At least ftell() is C.

We know that stat() isn't working as the OP expects.  I'd expect
ftell() to yield exactly the same results -- and it requires opening
the file and seeking to the end of it.  Furthermore, there's no
guarantee in C that the fseek()/ftell() trick will accurately yield
the size of a file.  Binary streams may legally be padded with an
implementation-defined number of null characters (N1370 7.21.2p3),
and "A binary stream need not meaningfully support fseek calls
with a whence value of SEEK_END" (7.21.9.2p3).  For text streams,
the value returned by ftell() isn't necessarily meaningful except
as an argument to fseek() (7.21.9.4p2).

A POSIX environment makes more guarantees -- but as long as you're
depending on POSIX, there's no good reason not to use stat()
(or fstat() or lstat()).

My point is that you suggested ftell() as a solution to the OP's
problem.  It isn't.

>> and what is "level 2"?
>
> Unixism. Just ignore it if it hurts you.

If you're referring to section 2 of the manual (ftell(2),
documentation available via "man 2 ftell"), I've never heard of
that being referred to as "level 2".  Try being a little less
condescending and actually answering the question.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#28151

Keith Thompson <kst-u@mib.org> writes:

> Alain Ketterlin <alain@dpt-info.u-strasbg.fr> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Alain Ketterlin <alain@dpt-info.u-strasbg.fr> writes:
>>>> felix <ckpradip@gmail.com> writes:
>>>>> if ( stat ( logFile, &results ) == 0 )
>>>>
>>>> Use ftell() instead (or lseek() at level 2).
>>>
>>> What makes you think that will yield better results,
>>
>> What makes you think it will not. At least ftell() is C.
>
> We know that stat() isn't working as the OP expects.  I'd expect
> ftell() to yield exactly the same results -- and it requires opening
> the file and seeking to the end of it.

If stat() doesn't give the correct result in the OP's use case (writing
chunks, and testing whether the size has reached a limit), it's probably
because the file is still open. And several people have suggested that
the problem was probably with the buffering. The doc of ftell() says (on
my system):

| The ftell() function obtains the current value of the file position
| indicator for the stream pointed to by stream.

In my opinion, that's a pretty good hint given the problem description.

> Furthermore, there's no guarantee in C that the fseek()/ftell() trick
> will accurately yield the size of a file. Binary streams may legally
> be padded with an implementation-defined number of null characters
> (N1370 7.21.2p3), and "A binary stream need not meaningfully support
> fseek calls with a whence value of SEEK_END" (7.21.9.2p3). For text
> streams, the value returned by ftell() isn't necessarily meaningful
> except as an argument to fseek() (7.21.9.4p2).

I know all this, thank you, but I have no indication that the OP is in
any of these cases. I just gave the OP a track to follow. He/she would
surely come back with another (and maybe more precise) question if
things turn out to be more difficult.

> A POSIX environment makes more guarantees -- but as long as you're
> depending on POSIX, there's no good reason not to use stat()
> (or fstat() or lstat()).

Keeping the file open is a good reason to not use stat() (see code
above).

> My point is that you suggested ftell() as a solution to the OP's
> problem.  It isn't.

OK, call it a hint if you want...

>>> and what is "level 2"?
>>
>> Unixism. Just ignore it if it hurts you.
>
> If you're referring to section 2 of the manual (ftell(2),
> documentation available via "man 2 ftell"), I've never heard of
> that being referred to as "level 2".

OK now you have. I didn't think it was that hard to understand, given
that lseek was two words away.

> Try being a little less condescending and actually answering the
> question.

Try being a little less condescending and actually helping people asking
for help instead of being pedantic (your words) on size units and
everything but the OP's problem.

-- Alain.

[toc] | [prev] | [next] | [standalone]

#28154

Alain Ketterlin wrote:
> Keith Thompson <kst-u@mib.org> writes:
> > Alain Ketterlin <alain@dpt-info.u-strasbg.fr> writes:
> >> Keith Thompson <kst-u@mib.org> writes:
> >>> Alain Ketterlin <alain@dpt-info.u-strasbg.fr> writes:
> >>>> felix <ckpradip@gmail.com> writes:
> >>>>> if ( stat ( logFile, &results ) == 0 )
> >>>>
> >>>> Use ftell() instead (or lseek() at level 2).
> >>> and what is "level 2"?
> >>
> >> Unixism. Just ignore it if it hurts you.
> >
> > If you're referring to section 2 of the manual (ftell(2),
> > documentation available via "man 2 ftell"), I've never heard of
> > that being referred to as "level 2".
> 
> OK now you have. I didn't think it was that hard to understand, given
> that lseek was two words away.

I didn't understand it either--I thought you meant to use a value of 2 
for whence, and I thought it was a strange way to express that. It never 
occurred to me you were referring to section 2 of the Unix Programmer's 
Manual.

[toc] | [prev] | [next] | [standalone]

#28156

In article <MPG.2b075cebd6906329989691@news.eternal-september.org>,
Philip Lantz  <prl@canterey.us> wrote:
...
>I didn't understand it either--I thought you meant to use a value of 2 
>for whence, and I thought it was a strange way to express that. It never 
>occurred to me you were referring to section 2 of the Unix Programmer's 
>Manual.

Well, live & learn!

See, the Usenet can be a helpful thing after all.

-- 
Just for a change of pace, this sig is *not* an obscure reference to
comp.lang.c...

[toc] | [prev] | [next] | [standalone]

#28163

Kenny McCormack wrote:
> 
> In article <MPG.2b075cebd6906329989691@news.eternal-september.org>,
> Philip Lantz  <prl@canterey.us> wrote:
> ...
> >I didn't understand it either--I thought you meant to use a value of 2 
> >for whence, and I thought it was a strange way to express that. It never 
> >occurred to me you were referring to section 2 of the Unix Programmer's 
> >Manual.
> 
> Well, live & learn!
> 
> See, the Usenet can be a helpful thing after all.

What am I supposed to have learned? Is the term "level" commonly used to 
identify a section of the Unix Programmer's Manual?

[toc] | [prev] | [next] | [standalone]

#28167

On Nov 10, 7:29 am, Philip Lantz <p...@canterey.us> wrote:
> Kenny McCormack wrote:
>
> > In article <MPG.2b075cebd6906329989...@news.eternal-september.org>,
> > Philip Lantz  <p...@canterey.us> wrote:
> > ...
> > >I didn't understand it either--I thought you meant to use a value of 2
> > >for whence, and I thought it was a strange way to express that. It never
> > >occurred to me you were referring to section 2 of the Unix Programmer's
> > >Manual.
>
> > Well, live & learn!
>
> > See, the Usenet can be a helpful thing after all.
>
> What am I supposed to have learned? Is the term "level" commonly used to
> identify a section of the Unix Programmer's Manual?

no

[toc] | [prev] | [next] | [standalone]

#28160

On 11/10/12 14:08, Alain Ketterlin wrote:
> Keith Thompson<kst-u@mib.org>  writes:
>> Alain Ketterlin<alain@dpt-info.u-strasbg.fr>  writes:
>>> Keith Thompson<kst-u@mib.org>  writes:
>
>>>> and what is "level 2"?
>>>
>>> Unixism. Just ignore it if it hurts you.
>>
>> If you're referring to section 2 of the manual (ftell(2),
>> documentation available via "man 2 ftell"), I've never heard of
>> that being referred to as "level 2".
>
> OK now you have. I didn't think it was that hard to understand, given
> that lseek was two words away.

I didn't understand it either.  I've never seen the expression used in 
the context of man pages.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#28197

On 11/09/2012 11:46 PM, Ian Collins wrote:
> On 11/10/12 14:08, Alain Ketterlin wrote:
>> Keith Thompson<kst-u@mib.org>  writes:
>>> Alain Ketterlin<alain@dpt-info.u-strasbg.fr>  writes:
>>>> Keith Thompson<kst-u@mib.org>  writes:
>>
>>>>> and what is "level 2"?
>>>>
>>>> Unixism. Just ignore it if it hurts you.
>>>
>>> If you're referring to section 2 of the manual (ftell(2),
>>> documentation available via "man 2 ftell"), I've never heard of
>>> that being referred to as "level 2".
>>
>> OK now you have. I didn't think it was that hard to understand, given
>> that lseek was two words away.
> 
> I didn't understand it either.  I've never seen the expression used in 
> the context of man pages.

Neither have I.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#28225

Ian Collins <ian-news@hotmail.com> writes:
> On 11/10/12 14:08, Alain Ketterlin wrote:
> > Keith Thompson<kst-u@mib.org>  writes:
> >> Alain Ketterlin<alain@dpt-info.u-strasbg.fr>  writes:
> >>> Keith Thompson<kst-u@mib.org>  writes:
> >
> >>>> and what is "level 2"?
> >>>
> >>> Unixism. Just ignore it if it hurts you.
> >>
> >> If you're referring to section 2 of the manual (ftell(2),
> >> documentation available via "man 2 ftell"), I've never heard of
> >> that being referred to as "level 2".
> >
> > OK now you have. I didn't think it was that hard to understand, given
> > that lseek was two words away.
> 
> I didn't understand it either.  I've never seen the expression used in
> the context of man pages.

Ditto, clearly our presumably-more-than-two decades of unix experience
are all for nought.  And it's not even being compact, as the expression
used is way more characters than the *absolutely standard* notation
which Keith followed up with, viz. ftell(2).

Looks like we've got a new level 2 usenet poster, IYKWIM...

Phil
-- 
Regarding TSA regulations:
How are four small bottles of liquid different from one large bottle?
Because four bottles can hold the components of a binary liquid explosive,
whereas one big bottle can't. -- camperdave responding to MacAndrew on /.

[toc] | [prev] | [next] | [standalone]

#28191

In article <87liea8dtp.fsf@dpt-info.u-strasbg.fr>,
Alain Ketterlin  <alain@dpt-info.u-strasbg.fr> wrote:
...
>> Try being a little less condescending and actually answering the
>> question.
>
>Try being a little less condescending and actually helping people asking
>for help instead of being pedantic (your words) on size units and
>everything but the OP's problem.

That's Kiki.  It wouldn't be Kiki if it didn't exhibit those sorts of
behaviors.

-- 
They say compassion is a virtue, but I don't have the time!

    - David Byrne -

[toc] | [prev] | [next] | [standalone]

#28157

On 11/09/2012 03:33 PM, Keith Thompson wrote:
> Alain Ketterlin <alain@dpt-info.u-strasbg.fr> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Alain Ketterlin <alain@dpt-info.u-strasbg.fr> writes:
>>>> felix <ckpradip@gmail.com> writes:
>>>>> if ( stat ( logFile, &results ) == 0 )
>>>>
>>>> Use ftell() instead (or lseek() at level 2).
>>>
>>> What makes you think that will yield better results,
>>
>> What makes you think it will not. At least ftell() is C.
> 
> We know that stat() isn't working as the OP expects.  I'd expect
> ftell() to yield exactly the same results -- and it requires opening
> the file and seeking to the end of it. ...

Opening the file and seeking to the end is not a problem; it's already
open, or at least it was at the time of the last write, and the current
write position was presumably at the end of the file, otherwise it
wouldn't be growing. I'd expect ftell() to give a better indication of
the bytes written than stat()=>st_size, since I wouldn't expect the
value returned by ftell() to be affected by issues such as buffering.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#28158

James Kuyper <jameskuyper@verizon.net> writes:
> On 11/09/2012 03:33 PM, Keith Thompson wrote:
>> Alain Ketterlin <alain@dpt-info.u-strasbg.fr> writes:
>>> Keith Thompson <kst-u@mib.org> writes:
>>>> Alain Ketterlin <alain@dpt-info.u-strasbg.fr> writes:
>>>>> felix <ckpradip@gmail.com> writes:
>>>>>> if ( stat ( logFile, &results ) == 0 )
>>>>>
>>>>> Use ftell() instead (or lseek() at level 2).
>>>>
>>>> What makes you think that will yield better results,
>>>
>>> What makes you think it will not. At least ftell() is C.
>> 
>> We know that stat() isn't working as the OP expects.  I'd expect
>> ftell() to yield exactly the same results -- and it requires opening
>> the file and seeking to the end of it. ...
>
> Opening the file and seeking to the end is not a problem; it's already
> open, or at least it was at the time of the last write, and the current
> write position was presumably at the end of the file, otherwise it
> wouldn't be growing. I'd expect ftell() to give a better indication of
> the bytes written than stat()=>st_size, since I wouldn't expect the
> value returned by ftell() to be affected by issues such as buffering.

Ok, good point.

That's assuming that the program that's querying the size of the file
is the same one that's writing to the file, and that the querying
code has access to the relevant FILE*.  That's not entirely obvious
from the original post, but it seems likely.

(As I said earlier, C doesn't guarantee that the value returned by
ftell() is meaningful for text streams, but that's unlikely to be
an issue for the OP.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#28159

On 11/09/2012 10:24 PM, Keith Thompson wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
...
>> Opening the file and seeking to the end is not a problem; it's already
>> open, or at least it was at the time of the last write, and the current
>> write position was presumably at the end of the file, otherwise it
>> wouldn't be growing. I'd expect ftell() to give a better indication of
>> the bytes written than stat()=>st_size, since I wouldn't expect the
>> value returned by ftell() to be affected by issues such as buffering.
> 
> Ok, good point.
> 
> That's assuming that the program that's querying the size of the file
> is the same one that's writing to the file, and that the querying
> code has access to the relevant FILE*.  That's not entirely obvious
> from the original post, but it seems likely.

The behavior that's controlled by the results of this query is the
creation of a new log file, so it never even occurred to me to consider
that the log file might be being written by some other program.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#28165

On 11/9/2012 10:24 PM, Keith Thompson wrote:
>[...]
> (As I said earlier, C doesn't guarantee that the value returned by
> ftell() is meaningful for text streams, but that's unlikely to be
> an issue for the OP.)

     If the all the logging happens in one place (or a small
number of nearby places), and if it all happens during one
execution of the program, the O.P. can do the entire job in
purely portable C.  Something like

	static FILE *logStream;
	static size_t logLength;

	void writeLog(const char *format, ...) {
	    if (logStream == NULL) {
	        logStream = openLog(...);
	        logLength = 0;
	    }

	    va_list ap;
	    va_start(ap, format);
	    logLength += vfprintf(format, ap);

	    va_end(ap);
	    if (logLength > LIMIT) {
	        closeLog(logStream);
	        logStream = NULL;
	    }
	}

... should do it, along with a little error-checking and such.

     (Okay, okay: The number of characters written to a stream is
not necessarily the same thing as the number of bytes stored on
a disk.  Nonetheless, for "start a new log when the old one gets
too big" purposes it should be close enough.)

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#28183

On 2012-11-10, Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
> On 11/9/2012 10:24 PM, Keith Thompson wrote:
>>[...]
>> (As I said earlier, C doesn't guarantee that the value returned by
>> ftell() is meaningful for text streams, but that's unlikely to be
>> an issue for the OP.)
>
>      If the all the logging happens in one place (or a small
> number of nearby places), and if it all happens during one
> execution of the program, the O.P. can do the entire job in
> purely portable C.  Something like
>
> 	static FILE *logStream;
> 	static size_t logLength;
>
> 	void writeLog(const char *format, ...) {
> 	    if (logStream == NULL) {
> 	        logStream = openLog(...);
> 	        logLength = 0;
> 	    }
>
> 	    va_list ap;
> 	    va_start(ap, format);
> 	    logLength += vfprintf(format, ap);

You mean
  	    logLength += vfprintf(logStream, format, ap);
?

[toc] | [prev] | [next] | [standalone]

#28186

On 11/10/2012 12:42 PM, Ike Naar wrote:
> On 2012-11-10, Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
>>[...]
>> 	    logLength += vfprintf(format, ap);
>
> You mean
>    	    logLength += vfprintf(logStream, format, ap);
> ?

     No, I *like* error messages ...   ;-)

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#28145

felix <ckpradip@gmail.com> writes:
> This method was written to create new Log File, when the size of the
> Log File reaches a max size defined by user [10MB in our case]. Here
> is the code snippet that does this check:
>
> //-- Code starts here : --
>
> static size_t LogSize = 1048576;
> bool CreateNewLogs = false;
>
>
> if ( stat ( logFile, &results ) == 0 )
> {
> 	if ( results.st_size > LogSize )
> 	{
> 		CreateNewLogs = true;
> 	}
> }
> //-- Code ends here   : --
>
> It is strange that the condition got satisfied when results.st_size =
> 2589116.  And we are sure that the size of the data that is written is
> between 50 to 100 bytes in one operation. And this check is done
> before writing into the LogFile.

It's been pointed out that 1048576 is the wrong value if you want 10 MB
(more pedantically, 10 MiB).  But LogSize is also the wrong type.
It should be the same type as the st_size member.

You probably want to use "const" rather than "static" in the definition
of LogSize, unless the value can change.

Neither of these is likely to be the cause of the problem you're seeing.
Since stat() is defined by POSIX, not by C, you'll likely get better
answers in comp.unix.programmer.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web