473,848 Members | 1,665 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

fread breaks file descriptors opened in "w" mode.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello all,

For some reasons, somewhere in a program, I'd like, if possible, to quickly
parse a whole file before rewinding it and letting the full analysis start.
My problem is that the FILE* I want do parse has been fopen'ed far away
from where I am and I don't know in which MODE my FILE* has been opened.
And additionally, my FILE* may not be a regular file, but a continuous
stream (pipe), in which case it is not rewindable.

So my program basically behaves like this:

void PreParsing( FILE *my_file )
{
/*
* Test if my FILE * is seekable
*/
if( fseek( my_file, 0, SEEK_SET ) == 0 ) {

/*
* If so, go on for the pre-parsing.
*/
//...
fread( buf, BUF_SIZE, 1, my_file );
//...

/*
* Rewind the file.
*/
if( fseek( my_file, 0, SEEK_SET ) != 0 ) {
// unexpected error since my FILE * was expected to be seekable.
}
}
}

* On both Linux 2.6.xx and Solaris 5.10,

when the my_file is a regular file that has been fopen'ed with "w" as mode,
- the first fseek returns 0 meaning success: my_file is seekable
- the fread returns 0 meaning that there was nothing to read: expected
since a file opened in "w" is truncated, hence is empty, and anyhow, cannot
be read!
- the second fseek returns 0 meaning success: my_file could be rewound.

when the my_file is a pipe that has been fopen'ed with "w" as mode,
- the first fseek returns -1 and errno is set to 29 (Illegal seek).
That's exactly what I expected since a pipe cannot be sought.

Ok. So, on Linux 2.6.xx and Solaris 5.10, my code behaves like I expected
for both regular files and pipes.

* On AIX 5.2,

when the my_file is a pipe that has been fopen'ed with "w" as mode,
- the first fseek returns -1 and errno is set to 29 (Illegal seek).
I'm still OK with that.

but...
when the my_file is a regular file that has been fopen'ed with "w" as mode,
- the first fseek returns 0 meaning success: my_file is seekable
- the fread returns 0 meaning that there was nothing to read: expected
since a file opened in "w" is truncated, hence is empty, and anyhow, cannot
be read!
- the second fseek returns -1 and sets errno to 9 (Bad file number)
I'm a little bit surprised by this error.

In fact, after having had a deeper look on that, it appears to me that a
fread attempt on a FILE * opened in "w" mode breaks it since any subsequent
operation (fseek, fwrite and even fclose !) fails with the error 9 (Bad
file number).
So, on AIX , my function fails to restore the FILE * state at its end.
So, I have a few questions:

- a fread on a FILE * opened in "w" will for sure return 0 item, but is it
really expected that it makes the given FILE * totally unusable even for
fclose !?! This behavior has been observed only on AIX. Linux and Solaris
works.
- given a FILE *, is there a better way to guess in which mode it has been
opened than attempting to read or write it and look at errors ?
- given a FILE *, is there a better way to guess if it can be sought than
attempting a fseek on it ?
PS: I Xposted my problem on both comp.lang.c and comp.unix.aix because I
have no idea whether this is an AIX specific problem or if the C norm
specifies explicitly that fread have unpredictable effects on a write-only
file descriptor. Anyhow, my goal is to find a portable solution that uses
as less platform specific stuff as possible.

Thanks for your advices.
Lénaïc ...still puzzled by AIX behavior...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkk jPpUACgkQjYEjJA TS6Bi55ACgj+Rbz OhyjDj63G+ciKo0 Iy1B
FuoAn3WsnRc69XX Di2KV0Wt4aOFo0B pf
=In7u
-----END PGP SIGNATURE-----
Nov 18 '08 #1
15 3196
On Nov 19, 12:15 am, Lénaïc Huard <lenaic.hu...@l aposte.netwrote :
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Please don't include that crap in your messages...
Hello all,

For some reasons, somewhere in a program, I'd like, if possible, to quickly
parse a whole file before rewinding it and letting the full analysis start.
My problem is that the FILE* I want do parse has been fopen'ed far away
from where I am and I don't know in which MODE my FILE* has been opened.
Well that's a bad thing, if you want truly meaningful results you
should enforce just one mode, binary or text.
And additionally, my FILE* may not be a regular file, but a continuous
stream (pipe), in which case it is not rewindable.
Load it in memory once, and don't bother with the actual file
rewinding.
So my program basically behaves like this:

void PreParsing( FILE *my_file )
{
/*
* Test if my FILE * is seekable
*/
if( fseek( my_file, 0, SEEK_SET ) == 0 ) {
That isn't testing anything really, except for that very fseek call.
>
/*
* If so, go on for the pre-parsing.
*/
//...
fread( buf, BUF_SIZE, 1, my_file );
I think you probably want fread(buf, 1, BUF_SIZE, my_file);
You should also observe the return value.

<snip observations of implementations >
* On AIX 5.2,
when the my_file is a regular file that has been fopen'ed with "w" as mode,
- the first fseek returns 0 meaning success: my_file is seekable
- the fread returns 0 meaning that there was nothing to read: expected
since a file opened in "w" is truncated, hence is empty, and anyhow, cannot
be read!
- the second fseek returns -1 and sets errno to 9 (Bad file number)
I'm a little bit surprised by this error.
Why? That's allowed by the standard.
In fact, after having had a deeper look on that, it appears to me that a
fread attempt on a FILE * opened in "w" mode breaks it since any subsequent
operation (fseek, fwrite and even fclose !) fails with the error 9 (Bad
file number).
So, on AIX , my function fails to restore the FILE * state at its end.
Well, that's also allowed by the standard (it does however sound like
your implementation has a bug)
So, I have a few questions:

- a fread on a FILE * opened in "w" will for sure return 0 item, but is it
really expected that it makes the given FILE * totally unusable even for
fclose !?! This behavior has been observed only on AIX. Linux and Solaris
works.
The standard allows any function of the standard library to set errno
for any reason. (there are exceptions)
- given a FILE *, is there a better way to guess in which mode it has been
opened than attempting to read or write it and look at errors ?
There's no way to do that in standard C.
- given a FILE *, is there a better way to guess if it can be sought than
attempting a fseek on it ?
No way in standard C.
PS: I Xposted my problem on both comp.lang.c and comp.unix.aix because I
have no idea whether this is an AIX specific problem or if the C norm
specifies explicitly that fread have unpredictable effects on a write-only
file descriptor. Anyhow, my goal is to find a portable solution that uses
as less platform specific stuff as possible.
Well, the standard is okay with this behavior. The implementation
probably has a bug. It's topical in both groups I believe.

Nov 18 '08 #2
Lénaïc Huard wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello all,

For some reasons, somewhere in a program, I'd like, if possible, to quickly
parse a whole file before rewinding it and letting the full analysis start.
My problem is that the FILE* I want do parse has been fopen'ed far away
from where I am and I don't know in which MODE my FILE* has been opened.
You have a design flaw.
And additionally, my FILE* may not be a regular file, but a continuous
stream (pipe), in which case it is not rewindable.
You have a second design flaw....

<snip>
>
So, I have a few questions:

- a fread on a FILE * opened in "w" will for sure return 0 item, but is it
really expected that it makes the given FILE * totally unusable even for
fclose
AFAIK reading from a write-only stream is undefined behaviour. Once you
do something undefined, who knows what will happen.

If you rip pages out of a library book, can you safely return it to the
library?

- given a FILE *, is there a better way to guess in which mode it has been
opened than attempting to read or write it and look at errors ?
Unfortunately the answer is "fix the design flaws in the programme"....
PS: I Xposted my problem on both comp.lang.c and comp.unix.aix
There may be AIX-specific answers to your problem but I can't comment on
that
Nov 18 '08 #3
In article <49************ **********@news .free.fr>,
Lénaïc Huard <le**********@l aposte.netwrote :
>For some reasons, somewhere in a program, I'd like, if possible, to quickly
parse a whole file before rewinding it and letting the full analysis start.
My problem is that the FILE* I want do parse has been fopen'ed far away
from where I am and I don't know in which MODE my FILE* has been opened.
And additionally, my FILE* may not be a regular file, but a continuous
stream (pipe), in which case it is not rewindable.
I'm at a loss as to why you want to handle the case where the file
has been opened for writing. If you want to read from a file, open
it for reading.

The other aspect - seekability - is entirely reasonable, but I don't
think you can handle it in standard C. If you are (as you appear to
be) using Posix systems, you can stat the underlying file descriptor
and seek only if it is a regular file.

I seem to recall using at least one system where fseek() succeeded
even on pipes provided the seek was within the existing stdio buffer,
so just because one fseek() succeeds, it doesn't mean others will.

-- Richard
--
Please remember to mention me / in tapes you leave behind.
Nov 18 '08 #4
On Nov 19, 12:43 am, Mark McIntyre <markmcint...@T ROUSERSspamcop. net>
wrote:
<snip>
AFAIK reading from a write-only stream is undefined behaviour.
I've recently asked this (or remember asking it), but I believe I
received no answers.
I've also searched the standard for the answer, with no luck. Anyone?
Nov 18 '08 #5
vi******@gmail. com a écrit :
>My problem is that the FILE* I want do parse has been
fopen'ed far away from where I am and I don't know in which MODE my FILE*
has been opened.

Well that's a bad thing, if you want truly meaningful results you
should enforce just one mode, binary or text.
Sorry, I wasn't clear enough. My problem is not between binary or text. I
deal only with binary files. The problem is between read or write.

I want to write a kind of « decorator » around a FILE *. And the constructor
of that decorator should parse the file is possible (i.e. if it is a
regular file opened for reading). But unfortunately, I don't know whether
those conditions are met when the constructor is invoked.
>And additionally, my FILE* may not be a regular file, but a continuous
stream (pipe), in which case it is not rewindable.

Load it in memory once, and don't bother with the actual file
rewinding.
But sometimes, this piece of code is used in programs working on continuous
streams. The data must me processed as they come. We can't wait for the
last item before starting to process the first one. And when used in this
context, the total amount of data that will have been read at the end of
the program is too big to fit into memory.
I would like to be able to detect such contexts and to skip the initial
parsing in those cases.
And of course, as I believe in Santa Claus, I try to do this without
modifying the prototypes of a lot of functions to add a read vs. write
information.
>So my program basically behaves like this:

void PreParsing( FILE *my_file )
{
/*
* Test if my FILE * is seekable
*/
if( fseek( my_file, 0, SEEK_SET ) == 0 ) {

That isn't testing anything really, except for that very fseek call.
Indeed, but this was already a workaround. My initial wish was to know
whether I have a chance that the second fseek works or if there is no
chance. In my case, this is nearly equivalent to know whether FILE * is a
regular file or a pipe.
But... I realize that may be such question ought to be put in
comp.unix.progr ammer instead...
>>
/*
* If so, go on for the pre-parsing.
*/
//...
fread( buf, BUF_SIZE, 1, my_file );

I think you probably want fread(buf, 1, BUF_SIZE, my_file);
You should also observe the return value.
Indeed. Sorry, the real program is better and checks the return. Promise!
>* On AIX 5.2,
when the my_file is a regular file that has been fopen'ed with "w" as
mode,
- the first fseek returns 0 meaning success: my_file is seekable
- the fread returns 0 meaning that there was nothing to read: expected
since a file opened in "w" is truncated, hence is empty, and anyhow,
cannot be read!
- the second fseek returns -1 and sets errno to 9 (Bad file number)
I'm a little bit surprised by this error.

Why? That's allowed by the standard.
I have no problem with the fact that fseek returns an error. But the kind of
error make me feel that the fread didn't simply return 0 item, it also
closed the file descriptor. Further in the program, fclose also issues an
EBADF (Bad file number) error.

My concern is not « fseek shouldn't fail ». It's more : « Should fread
executed on an un-readable stream just return an error or is its behavior
completely undefined (including closing the file descriptor, corrupting
memory, crashing or potentially anything else.) »
>In fact, after having had a deeper look on that, it appears to me that a
fread attempt on a FILE * opened in "w" mode breaks it since any
subsequent operation (fseek, fwrite and even fclose !) fails with the
error 9 (Bad file number).
So, on AIX , my function fails to restore the FILE * state at its end.

Well, that's also allowed by the standard (it does however sound like
your implementation has a bug)

The standard allows any function of the standard library to set errno
for any reason. (there are exceptions)
I understand your point: the standard library functions can, according to
the standard, legally fail at any call and return an appropriate error.
But I would expect that any illegal operation (like reading an un-readable
stream) would return an error, set the errno, and leave the stream
un-modified. And instead of this, I have the feeling that my file
descriptor is closed.
Nov 19 '08 #6
Richard Tobin a écrit :
The other aspect - seekability - is entirely reasonable, but I don't
think you can handle it in standard C. If you are (as you appear to
be) using Posix systems, you can stat the underlying file descriptor
and seek only if it is a regular file.
Sounds to be exactly what I was looking for... I'm still wondering why I
didn't think about stat before.
Thanks!
I seem to recall using at least one system where fseek() succeeded
even on pipes provided the seek was within the existing stdio buffer,
so just because one fseek() succeeds, it doesn't mean others will.
Sounds to be an excellent reason for not testing the seekability with fseek!
Nov 19 '08 #7
Lénaïc Huard wrote:
vi******@gmail. com a �crit :
My problem is that the FILE* I want do parse has been
fopen'ed far away from where I am and I don't know in which MODE my FILE*
has been opened.
Well that's a bad thing, if you want truly meaningful results you
should enforce just one mode, binary or text.

Sorry, I wasn't clear enough. My problem is not between binary or text. I
deal only with binary files. The problem is between read or write.
If you don't know whether a given file has been opened for reading or
writing, you need to re-design your code so that you do know.
I want to write a kind of � decorator � around a FILE *. And the constructor
of that decorator should parse the file is possible (i.e. if it is a
regular file opened for reading). But unfortunately, I don't know whether
those conditions are met when the constructor is invoked.
C doesn't have constructors. Are you actually working in C++? in that
case your question should be re-directed to comp.lang.c++.

....
And of course, as I believe in Santa Claus, I try to do this without
modifying the prototypes of a lot of functions to add a read vs. write
information.
Well, I don't see what Santa has to do with that, but if there's some
legitimate reason why the most obvious fix is s unacceptable, you'll
need to find some other way of passing the information around. One
option is to create a structure with at least two members: a FILE *
and something that keeps track of what mode the file was opened in.
Nov 19 '08 #8
On Nov 18, 2:15*pm, Lénaïc Huard <lenaic.hu...@l aposte.netwrote :
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello all,

For some reasons, somewhere in a program, I'd like, if possible, to quickly
parse a whole file before rewinding it and letting the full analysis start.
My problem is that the FILE* I want do parse has been fopen'ed far away
from where I am and I don't know in which MODE my FILE* has been opened.
And additionally, my FILE* may not be a regular file, but a continuous
stream (pipe), in which case it is not rewindable.

So my program basically behaves like this:

void PreParsing( FILE *my_file )
{
* /*
* ** Test if my FILE * is seekable
* **/
* if( fseek( my_file, 0, SEEK_SET ) == 0 ) {

* * /*
* * ** If so, go on for the pre-parsing.
* * **/
* * //...
* * fread( buf, BUF_SIZE, 1, my_file );
* * //...

* * /*
* * ** Rewind the file.
* * **/
* * if( fseek( my_file, 0, SEEK_SET ) != 0 ) {
* * * // unexpected error since my FILE * was expected to be seekable.
* * }
* }

}

* On both Linux 2.6.xx and Solaris 5.10,

when the my_file is a regular file that has been fopen'ed with "w" as mode,
*- the first fseek returns 0 meaning success: my_file is seekable
*- the fread returns 0 meaning that there was nothing to read: expected
since a file opened in "w" is truncated, hence is empty, and anyhow, cannot
be read!
*- the second fseek returns 0 meaning success: my_file could be rewound..

when the my_file is a pipe that has been fopen'ed with "w" as mode,
*- the first fseek returns -1 and errno is set to 29 (Illegal seek).
That's exactly what I expected since a pipe cannot be sought.

Ok. So, on Linux 2.6.xx and Solaris 5.10, my code behaves like I expected
for both regular files and pipes.

* On AIX 5.2,

when the my_file is a pipe that has been fopen'ed with "w" as mode,
*- the first fseek returns -1 and errno is set to 29 (Illegal seek).
I'm still OK with that.

but...
when the my_file is a regular file that has been fopen'ed with "w" as mode,
*- the first fseek returns 0 meaning success: my_file is seekable
*- the fread returns 0 meaning that there was nothing to read: expected
since a file opened in "w" is truncated, hence is empty, and anyhow, cannot
be read!
*- the second fseek returns -1 and sets errno to 9 (Bad file number)
I'm a little bit surprised by this error.

In fact, after having had a deeper look on that, it appears to me that a
fread attempt on a FILE * opened in "w" mode breaks it since any subsequent
operation (fseek, fwrite and even fclose !) fails with the error 9 (Bad
file number).
So, on AIX , my function fails to restore the FILE * state at its end.

So, I have a few questions:

*- a fread on a FILE * opened in "w" will for sure return 0 item, but is it
really expected that it makes the given FILE * totally unusable even for
fclose !?! This behavior has been observed only on AIX. Linux and Solaris
works.
*- given a FILE *, is there a better way to guess in which mode it has been
opened than attempting to read or write it and look at errors ?
*- given a FILE *, is there a better way to guess if it can be sought than
attempting a fseek on it ?

PS: I Xposted my problem on both comp.lang.c and comp.unix.aix because I
have no idea whether this is an AIX specific problem or if the C norm
specifies explicitly that fread have unpredictable effects on a write-only
file descriptor. Anyhow, my goal is to find a portable solution that uses
as less platform specific stuff as possible.

Thanks for your advices.
Lénaïc ...still puzzled by AIX behavior...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkk jPpUACgkQjYEjJA TS6Bi55ACgj+Rbz OhyjDj63G+ciKo0 Iy1B
FuoAn3WsnRc69XX Di2KV0Wt4aOFo0B pf
=In7u
-----END PGP SIGNATURE-----
Partial solution - you can discover if it is a PIPE or a Special
Device
by doing a "stat" on it and checking the
mode:

Passed in as a parm: FILE *fp;

struct stat my_stat;
mode_t the_type;

fstat ( fileno(fp), &my_stat);

/* apply mask to get just file_type */
the_type = (my_stat.st_mod e & _S_IFMT )

if ( the_type == _S_IFIFO ) {
printf("Its a pipe\n");
}else{
if ( the_type == _S_IFBLK ) {
printf("It is a Block Special device\n");
}else{
if ( the_type == _S_IFCHR ) {
printf("It is a Character Special device\n");
....... etc....

-tony
Nov 19 '08 #9
On Tue, 18 Nov 2008 17:14:21 -0800 (PST),
be**********@co n-way.com <be**********@c on-way.comwrote:
On Nov 18, 2:15Â*pm, Lénaïc Huard <lenaic.hu...@l aposte.netwrote :
>For some reasons, somewhere in a program, I'd like, if possible, to quickly
parse a whole file before rewinding it and letting the full analysis start.
My problem is that the FILE* I want do parse has been fopen'ed far away
from where I am and I don't know in which MODE my FILE* has been opened.
And additionally, my FILE* may not be a regular file, but a continuous
stream (pipe), in which case it is not rewindable.
Partial solution - you can discover if it is a PIPE or a Special
Device
by doing a "stat" on it and checking the
mode:
[snip code using fstat() and its associated macros]

Of course, this is not standard C, but POSIX. If you are indeed using a
POSIX or POSIX-like system, and you want to use that API, you
should probably be discussing this in comp.unix.progr ammer, as the
people there tend to know a lot more about POSIX, on average, than the
people here.

Martien
--
|
Martien Verbruggen | This matter is best disposed of from a great
| height, over water.
|
Nov 19 '08 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

0
1350
by: Masiar Farahani | last post by:
Hi, Is there a option in PythonWin to write files in unix file mode? Regards Masiar
7
3811
by: Scott Chapman | last post by:
Hi! I'd like a "file" on the Linux box to actually be the input and output of a Python script. Anything written to the file would be sent to a database and anything read from the file would come from the database. I know how to do the database end of this but I'm not sure if a script can be hooked to a "file" transparently. The script would probably have to be run as a daemon. I doubt there's enough magic in the Linux world to make...
6
1904
by: Uwe Mayer | last post by:
Hi, when extending a build in class, what does the constructor __init__(...) have to return? and how does the constructor call its base-class construtor? (or is this done automatically?) I want to derive from "file" to create a class that reads record from a binary file:
11
2178
by: David Morgenthaler | last post by:
How does one overide the iterator implied by the construct "for line in file:"? For example, suppose I have a file containing row,col pairs on each line, and I wish to write a subclass of file that will transform these to x,y coordinates using an affine transform. I'd like it to look something like this (but this clearly doesn't work): class myFile(file): def __init__(self,name,affine):
1
10715
by: Matt | last post by:
When we click Browse button, <input type="FILE">, can we set the default of the directory to open?? For example, C:\MYFILES are open when the file open dialog is opened. please advise. thanks!!
1
2431
by: jingkun Hu via .NET 247 | last post by:
(Type your message here) I'm upgrading a VC++ 6 project to VC.NET 2003. The compiling isOK but not linking. The error message is "mfc42.lib cannot beopened". I looked through every setting of compiling and linkingand didn't find mfc42.lib in there. I understand that VC.NET2003 uses mfc71.lib. But how does the environment requiresmfc42.lib? Please help! -------------------------------- From: jingkun Hu ----------------------- Posted...
4
5836
by: Joe Lester | last post by:
I'm trying to figure out what the optimal Postgres configuration would be for my server (with 200 connecting clients, even though I'd really like to get it up to 500). I've got a 700 MHz eMac running Mac OS 10.3.2 (Panther) with 512 MB of RAM. I've messed around with some settings but I'm still getting an occasional "out of file descriptor" error, especially when performing a VACUUM. Like so... 2004-04-13 23:30:05 LOG: out of file...
1
13060
by: weird0 | last post by:
System.Data.SqlClient.SqlException: An attempt to attach an auto- named database for file "Location" failed. A database with the same name exists, or specified file cannot be opened, or it is located on UNC share. I am getting the above the exception while connecting to the db and i have written a web-service... i.e. a webmethod. What do I do? Why am i getting this error ? How can i remove this
9
3172
by: hstagni | last post by:
I tried to use fseek in a file opened for writing: ------ BEGIN ------- int main() { char c; FILE *fp; fp=fopen("texto", "wb"); putc('a', fp); putc('b', fp);
2
7957
by: jjlagtap | last post by:
Hey everyone When I try to open a file i get the Exception listed below. The weird thing is it works when I run the web app locally and when i use a remote server and open a file on my computer. When someone else uses the web app and tries to open a file using the remote server the error below happens. any help? **Code** C# - filepath is a valid file name which is passed via the form. System.IO.BinaryReader br = new...
0
9893
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
9738
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
10664
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
1
10722
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
1
7894
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
5735
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
0
5919
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
4544
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
3
3175
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.