473,224 Members | 1,440 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,224 software developers and data experts.

fseek on a file opened with _popen

Hello

Recently I discovered some problem. I have some C code
which determines how many bytes are available in a
file. Later I use this information to malloc a buffer of
the correct size before I read the bytes.
Determining the number of bytes available in a
file is done in 5 steps:

1. Use tell(aFile) to get the current position.
2. Use fseek(aFile, 0, SEEK_END) to move to the end.
3. Get the current position with tell(aFile) (this is the
size of the file in bytes).
4. I move to the position which I got in step 1 with fseek().
5. Subtract the current position from the file size to
get the number of bytes available.

This code is certainly not the most elegant solution but
it is portable. The code works for normal files under
windows and linux. The portability is also the reason
why I use tell() and fseek() instead of windows specific
code.

When I open a file with _popen I get a different result:
- Under linux the tell() of step 1 returns -1 which means
the file is not seekable. I can recognice this situation
and react accordingly (I cannot malloc the buffer beforehand.
Instead I malloc a smaller buffer which is realloced until
all bytes are read).
- Under windows the tell() of step 1 returns 0 which
means the file is seekable and is currently at position 0.
The other calls of fseek() and ftell() succeed also and
indicate that the number of available bytes is 0.
Therefore my program thinks that there are no bytes
available in the file opened with _popen.

The information that it is a file opened with _popen is
not available at that place in my program.

Now my question:
Is it possible to find out that a file (available in a
variable of type FILE * ) was opened with _popen?

Something like: Turn the FILE * into a handle and ask a
function about the file type. It is no problem for me to
insert windows specific code under an #ifdef

Thanks in advance Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
Feb 28 '08 #1
13 4417
th***********@gmx.at wrote:
Hello

Recently I discovered some problem. I have some C code
which determines how many bytes are available in a
file.
[snip]
The code works for normal files under
windows and linux.
[snip]
When I open a file with _popen I get a different result:
- Under linux the tell() of step 1 returns -1 which means
the file is not seekable. I can recognice this situation
and react accordingly (I cannot malloc the buffer beforehand.
Instead I malloc a smaller buffer which is realloced until
all bytes are read).
I hope you don't grow it a byte at a time :-)
- Under windows the tell() of step 1 returns 0 which
means the file is seekable and is currently at position 0.
The other calls of fseek() and ftell() succeed also and
indicate that the number of available bytes is 0.
Therefore my program thinks that there are no bytes
available in the file opened with _popen.
The information that it is a file opened with _popen is
not available at that place in my program.
Could you consider making it available, by providing a wrapper
mechanism? (That would probably be my favoured approach, rather
than looking for platform specifics...)
Now my question:
Is it possible to find out that a file (available in a
variable of type FILE * ) was opened with _popen?
As _popen is not part of the C standard, it's not really
something we would consider here. You'd probably do better
asking in a Windows newsgroup.
Feb 28 '08 #2
th***********@gmx.at wrote:
Hello

Recently I discovered some problem. I have some C code
which determines how many bytes are available in a
file. Later I use this information to malloc a buffer of
the correct size before I read the bytes.
Determining the number of bytes available in a
file is done in 5 steps:

1. Use tell(aFile) to get the current position.
Don't you man ftell() rather than tell()?
If not you're most üprobably lost here as that won't be a standard function.
2. Use fseek(aFile, 0, SEEK_END) to move to the end.
3. Get the current position with tell(aFile) (this is the
size of the file in bytes).
4. I move to the position which I got in step 1 with fseek().
5. Subtract the current position from the file size to
get the number of bytes available.

This code is certainly not the most elegant solution but
it is portable. The code works for normal files under
windows and linux. The portability is also the reason
why I use tell() and fseek() instead of windows specific
code.

When I open a file with _popen I get a different result:
no function _popen() in standard C (I think). In POSIX there's popen() (i.e.
without the leading underscore)
- Under linux the tell() of step 1 returns -1 which means
the file is not seekable. I can recognice this situation
and react accordingly (I cannot malloc the buffer beforehand.
Instead I malloc a smaller buffer which is realloced until
all bytes are read).
- Under windows the tell() of step 1 returns 0 which
means the file is seekable and is currently at position 0.
The other calls of fseek() and ftell() succeed also and
indicate that the number of available bytes is 0.
Therefore my program thinks that there are no bytes
available in the file opened with _popen.

The information that it is a file opened with _popen is
not available at that place in my program.

Now my question:
Is it possible to find out that a file (available in a
variable of type FILE * ) was opened with _popen?

Something like: Turn the FILE * into a handle and ask a
function about the file type. It is no problem for me to
insert windows specific code under an #ifdef
OT here (I think) but "int filno(FILE *stream);" might be what you're
looking for

Bye, Jojo
Feb 28 '08 #3
In article <fq**********@aioe.org>,
Mark Bluemel <ma**********@pobox.comwrote:
> (I cannot malloc the buffer beforehand.
Instead I malloc a smaller buffer which is realloced until
all bytes are read).
>I hope you don't grow it a byte at a time :-)
That's not much of a problem with most malloc() implementations.

-- Richard
--
:wq
Feb 28 '08 #4
In article <0a**********************************@z17g2000hsg. googlegroups.com>,
<th***********@gmx.atwrote:
>- Under linux the tell() of step 1 returns -1 which means
the file is not seekable. I can recognice this situation
and react accordingly (I cannot malloc the buffer beforehand.
Instead I malloc a smaller buffer which is realloced until
all bytes are read).
Why not use this strategy always?

As an optimisation, you could use the ftell() strategy to determine
the initial size to malloc().

-- Richard
--
:wq
Feb 28 '08 #5
On 28 Feb., 13:44, Mark Bluemel <mark_blue...@pobox.comwrote:
thomas.mer...@gmx.at wrote:
Hello
Recently I discovered some problem. I have some C code
which determines how many bytes are available in a
file.

[snip]
The code works for normal files under
windows and linux.

[snip]
When I open a file with _popen I get a different result:
- Under linux the tell() of step 1 returns -1 which means
the file is not seekable. I can recognice this situation
and react accordingly (I cannot malloc the buffer beforehand.
Instead I malloc a smaller buffer which is realloced until
all bytes are read).

I hope you don't grow it a byte at a time :-)
Actually I grow it in steps of 4096.
- Under windows the tell() of step 1 returns 0 which
means the file is seekable and is currently at position 0.
The other calls of fseek() and ftell() succeed also and
indicate that the number of available bytes is 0.
Therefore my program thinks that there are no bytes
available in the file opened with _popen.
The information that it is a file opened with _popen is
not available at that place in my program.

Could you consider making it available, by providing a wrapper
mechanism? (That would probably be my favoured approach, rather
than looking for platform specifics...)
A simplified version of the function using this functionality
is (please don't start nitpicking):

-----------------------------------------------
#include "stdlib.h"
#include "stdio.h"

#define READ_BLOCK_SIZE 4096
#define SIZ_STRI(len) ((sizeof(struct stristruct) - \
sizeof(unsigned char)) + (len) * sizeof(unsigned char))

typedef struct stristruct {
unsigned long int size;
unsigned char mem[1];
} *stritype;

stritype filGets (FILE *aFile, long length)

{
long current_file_position;
unsigned long int bytes_requested;
unsigned long int bytes_there;
unsigned long int read_size_requested;
unsigned long int block_size_read;
unsigned long int allocated_size;
unsigned long int result_size;
unsigned char *memory;
stritype resized_result;
stritype result;

/* filGets */
if (length < 0) {
result = NULL;
} else {
bytes_requested = (unsigned long int) length;
allocated_size = bytes_requested;
result = (stritype) malloc(SIZ_STRI(allocated_size));
if (result == NULL) {
/* Determine how many bytes are available in aFile */
if ((current_file_position = ftell(aFile)) != -1) {
fseek(aFile, 0, SEEK_END);
bytes_there = (ftell(aFile) - current_file_position);
fseek(aFile, current_file_position, SEEK_SET);
/* Now we know that bytes_there bytes are available
in aFile */
if (bytes_there < bytes_requested) {
allocated_size = bytes_there;
result = (stritype) malloc(SIZ_STRI(allocated_size));
if (result == NULL) {
return(NULL);
} /* if */
} else {
return(NULL);
} /* if */
} /* if */
} /* if */
if (result != NULL) {
/* We have allocated at least as many bytes as
are available in the file */
result_size = (unsigned long int) fread(result->mem, 1,
(size_t) allocated_size, aFile);
} else {
/* We do not know how many bytes are avaliable therefore we
read blocks of READ_BLOCK_SIZE until we reach EOF */
allocated_size = READ_BLOCK_SIZE;
result = (stritype) malloc(SIZ_STRI(allocated_size));
if (result == NULL) {
return(NULL);
} else {
read_size_requested = READ_BLOCK_SIZE;
if (read_size_requested bytes_requested) {
read_size_requested = bytes_requested;
} /* if */
block_size_read = fread(result->mem, 1,
read_size_requested, aFile);
result_size = block_size_read;
while (block_size_read == READ_BLOCK_SIZE &&
result_size < bytes_requested) {
allocated_size = result_size + READ_BLOCK_SIZE;
resized_result = (stritype)
realloc(result, SIZ_STRI(allocated_size));
if (resized_result == NULL) {
free(result);
return(NULL);
} else {
result = resized_result;
memory = (unsigned char *) result->mem;
read_size_requested = READ_BLOCK_SIZE;
if (result_size + read_size_requested >
bytes_requested) {
read_size_requested = bytes_requested - result_size;
} /* if */
block_size_read = fread(&memory[result_size], 1,
read_size_requested, aFile);
result_size += block_size_read;
} /* if */
} /* while */
} /* if */
} /* if */
result->size = result_size;
if (result_size < allocated_size) {
resized_result = (stritype)
realloc(result, SIZ_STRI(result_size));
if (resized_result == NULL) {
free(result);
return(NULL);
} else {
result = resized_result;
} /* if */
} /* if */
} /* if */
return(result);
} /* filGets */
-------------------------------------------

The function _popen() is not a standard function, but popen()
is. Btw.: Under windows I use MinGW and there the function
is also popen(). The problem stays open:

if you open a file with popen() (MinGW probably also cygwin)
under windows and you do a ftell() or fseek() you just
succeed as if it is an empty file. If you do the same in
linux the ftell() and fseek() functions return -1 which
indicate that the file is not seekable.

If someone has an idea: Please help.

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
Feb 28 '08 #6
On 28 Feb., 14:19, rich...@cogsci.ed.ac.uk (Richard Tobin) wrote:
In article <0a41826a-30d2-4e47-b1ed-be13144bf...@z17g2000hsg.googlegroups.com>,

<thomas.mer...@gmx.atwrote:
- Under linux the tell() of step 1 returns -1 which means
the file is not seekable. I can recognice this situation
and react accordingly (I cannot malloc the buffer beforehand.
Instead I malloc a smaller buffer which is realloced until
all bytes are read).

Why not use this strategy always?

As an optimisation, you could use the ftell() strategy to determine
the initial size to malloc().
This is just what I want. But for a pipe created with popen this
strategy is not possible: You cannot know how big a pipe can
grow. Therefore ftell() and fseek() return -1 for pipes.
Under windows it does not work for files (pipes) opened with
_popen() since ftell() and fseek() return 0 instead of -1.
Therefore I look for a possibility to recognize this situation.

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
Feb 28 '08 #7
On 28 Feb., 13:48, "Joachim Schmitz" <nospam.j...@schmitz-digital.de>
wrote:
thomas.mer...@gmx.at wrote:
Hello
Recently I discovered some problem. I have some C code
which determines how many bytes are available in a
file. Later I use this information to malloc a buffer of
the correct size before I read the bytes.
Determining the number of bytes available in a
file is done in 5 steps:
1. Use tell(aFile) to get the current position.

Don't you man ftell() rather than tell()?
Yes you are right: I mean ftell()
If not you're most üprobably lost here as that won't be a standard function.
2. Use fseek(aFile, 0, SEEK_END) to move to the end.
3. Get the current position with tell(aFile) (this is the
size of the file in bytes).
4. I move to the position which I got in step 1 with fseek().
5. Subtract the current position from the file size to
get the number of bytes available.
This code is certainly not the most elegant solution but
it is portable. The code works for normal files under
windows and linux. The portability is also the reason
why I use tell() and fseek() instead of windows specific
code.
When I open a file with _popen I get a different result:

no function _popen() in standard C (I think). In POSIX there's popen() (i.e.
without the leading underscore)
I looked at the popen() more closely and I use popen()
under linux (gcc) and under windows (MinGW). the only place
using _popen() would be under windows (MSVC). But the actual
problem occours under windows(MinGW). So I can claim that
I actually use the POSIX popen().
- Under linux the tell() of step 1 returns -1 which means
the file is not seekable. I can recognice this situation
and react accordingly (I cannot malloc the buffer beforehand.
Instead I malloc a smaller buffer which is realloced until
all bytes are read).
- Under windows the tell() of step 1 returns 0 which
means the file is seekable and is currently at position 0.
The other calls of fseek() and ftell() succeed also and
indicate that the number of available bytes is 0.
Therefore my program thinks that there are no bytes
available in the file opened with _popen.
The information that it is a file opened with _popen is
not available at that place in my program.
Now my question:
Is it possible to find out that a file (available in a
variable of type FILE * ) was opened with _popen?
Something like: Turn the FILE * into a handle and ask a
function about the file type. It is no problem for me to
insert windows specific code under an #ifdef

OT here (I think) but "int filno(FILE *stream);" might be what you're
looking for
Does the fileno() function return a file handle under
windows?

May be I can use fstat and check for S_ISFIFO.
If that works MinGW has a bug.

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
Feb 28 '08 #8
In article <cf**********************************@34g2000hsz.g ooglegroups.com>,
<th***********@gmx.atwrote:
>- Under linux the tell() of step 1 returns -1 which means
the file is not seekable. I can recognice this situation
and react accordingly (I cannot malloc the buffer beforehand.
Instead I malloc a smaller buffer which is realloced until
all bytes are read).
>Why not use this strategy always?
>As an optimisation, you could use the ftell() strategy to determine
the initial size to malloc().
>This is just what I want. But for a pipe created with popen this
strategy is not possible: You cannot know how big a pipe can
grow.
You misunderstand. *Don't* try to recognise the situation. *Always*
use the grow-the-buffer-as-you-read approach, so that you don't have
to know the size in advance.

But use the result of the ftell() strategy for the initial size.
It will be wrong if it happens to be a pipe, but it doesn't matter
that it's wrong - you'll just start with a buffer of zero bytes and
grow it to the right size as you read.

-- Richard
--
:wq
Feb 28 '08 #9
th***********@gmx.at wrote:
>...So I can claim that
I actually use the POSIX popen().
Which is a POSIX standard (see comp.unix.programmer) not a C standard.
Feb 28 '08 #10
th***********@gmx.at wrote:
On 28 Feb., 13:48, "Joachim Schmitz" <nospam.j...@schmitz-digital.de>
wrote:
>thomas.mer...@gmx.at wrote:
<snip>
>>Now my question:
Is it possible to find out that a file (available in a
variable of type FILE * ) was opened with _popen?
>>Something like: Turn the FILE * into a handle and ask a
function about the file type. It is no problem for me to
insert windows specific code under an #ifdef

OT here (I think) but "int filno(FILE *stream);" might be what you're
looking for

Does the fileno() function return a file handle under
windows?
No idea, but it does in POSIX
$ man fileno
....
fileno - Maps a stream pointer to a file descriptor
....
The fileno() function returns the file descriptor of a stream
May be I can use fstat and check for S_ISFIFO.
Indeed. But you could also use stat(), which works on a filename rather than
on a file descriptor.
If that works MinGW has a bug.
Bye, Jojo
Feb 28 '08 #11
Mark Bluemel wrote:
th***********@gmx.at wrote:
>...So I can claim that
I actually use the POSIX popen().

Which is a POSIX standard (see comp.unix.programmer) not a C standard.
Which he said.

Bye, Jojo
Feb 28 '08 #12
On 28 Feb., 15:53, rich...@cogsci.ed.ac.uk (Richard Tobin) wrote:
In article <cfd1408d-e3dc-4912-8f2f-58c3e7211...@34g2000hsz.googlegroups.com>,

<thomas.mer...@gmx.atwrote:
- Under linux the tell() of step 1 returns -1 which means
the file is not seekable. I can recognice this situation
and react accordingly (I cannot malloc the buffer beforehand.
Instead I malloc a smaller buffer which is realloced until
all bytes are read).
Why not use this strategy always?
As an optimisation, you could use the ftell() strategy to determine
the initial size to malloc().
This is just what I want. But for a pipe created with popen this
strategy is not possible: You cannot know how big a pipe can
grow.

You misunderstand. *Don't* try to recognise the situation. *Always*
use the grow-the-buffer-as-you-read approach, so that you don't have
to know the size in advance.
You are right: I missunderstand you, sorry.
But use the result of the ftell() strategy for the initial size.
It will be wrong if it happens to be a pipe, but it doesn't matter
that it's wrong - you'll just start with a buffer of zero bytes and
grow it to the right size as you read.
Sounds not bad, I will think over that.
The function does not always read the rest of a file.
It gets a length limit. The prototype of filGets is:

stritype filGets (FILE *aFile, long length)

My general strategy to the function is:

A) Do a malloc() for the requested length
B) Attempt to read the requested amount of bytes
(not all requested bytes may be available).
C) Realloc() the malloced area to the actual size.

So it is quite simple in the normal case.
But this function is also used to read whole files.
This is done by using very high values for 'length'.
Now two things can happen.

- The malloc() succeeds: The general strategy works.
- The malloc() fails: This is the case I was talking
about in this discussion.

If the malloc() fails it still would have higher
performance to just use one malloc() and one fread().
Therefore I started to write code to find out the
available bytes. I belived that the ftell()/fseek()
strategy would work exactly for all files where it
is possible to determine the available bytes. Well,
this was theory and windows under MinGW is something
different.

For me is the 'read from the file in small chunks"
strategy only the last resort. Not because I think
that the reading would be slower, but because it
needs lots of reallocs for a probably very big
buffer. So some bad things can happen:

a) The reallocs cost time.
b) It may fail because the heap was thrashed to
much (a single malloc would have succeeded).

Btw.: In the meantime I tried to use fstat() and
S_ISREG() and use the ftell()/fseek() strategy only
for regular files.

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
Feb 28 '08 #13
On 28 Feb., 15:57, "Joachim Schmitz" <nospam.j...@schmitz-digital.de>
wrote:
thomas.mer...@gmx.at wrote:
On 28 Feb., 13:48, "Joachim Schmitz" <nospam.j...@schmitz-digital.de>
wrote:
thomas.mer...@gmx.at wrote:
<snip>
>Now my question:
Is it possible to find out that a file (available in a
variable of type FILE * ) was opened with _popen?
>Something like: Turn the FILE * into a handle and ask a
function about the file type. It is no problem for me to
insert windows specific code under an #ifdef
OT here (I think) but "int filno(FILE *stream);" might be what you're
looking for
Does the fileno() function return a file handle under
windows?

No idea, but it does in POSIX
$ man fileno
...
fileno - Maps a stream pointer to a file descriptor
...
The fileno() function returns the file descriptor of a stream
May be I can use fstat and check for S_ISFIFO.

Indeed. But you could also use stat(), which works on a filename rather than
on a file descriptor.
If I would know the filename at this place, I would
probably also know the type of the file without
referring to fstat().

Btw.: I tested with fstat() and it works under
linux and windows. Currently I do the ftell()/fstat()
strategy to determine the size of a file only for
regular files.
If that works MinGW has a bug.
Since my solution works I would say that
MinGw has a bug when using ftell()/fseek() for pipes:
Instead of -1 the functions return 0 for pipes (at least for
the pipes opened with popen() ).

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
Feb 28 '08 #14

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

Similar topics

1
by: Michael | last post by:
Hello, Not sure if this is the right message board but I have an interesting problem. Using Visual Studio .NET, C++, I want to write an all-encompassing C++ program to download new files from...
62
by: Christopher Benson-Manica | last post by:
On thinking about the "replace a word in a file" thread, I wondered how easy it would be to accomplish the same thing with only one file pointer. This led me to some questions... "For a text...
15
by: TJ Walls | last post by:
Hello All, I am baffled ... I am trying to improve the speed of a program that I have written that performs random access within a file. It relies heavily on fseek and is very slow. To test, I...
20
by: Xenos | last post by:
Can anyone tell me what the standard says about using fseek (on a binary file) to seek past the end-of-file? I can't find anything in my (draft) copy of the standard, nor in the FAQ. Thanks
2
by: John | last post by:
I have a file open using fopen and am reaing using fread. Does this mean that the OS (linux) already buffers this file? What is the buffer size? Can I change it? Thanks, --j
2
by: cedarson | last post by:
I am writing a program and have been instructeed to use the 'fseek', 'ftell', and 'stat' functions, however, after looking in the online manual for each of these, I am still unsure on how to use...
10
by: Kenneth Brody | last post by:
I recently ran into an "issue" related to text files and ftell/fseek, and I'd like to know if it's a bug, or simply an annoying, but still conforming, implementation. The platform is Windows,...
14
by: Maria Mela | last post by:
Hello everyone... I´ve a problem with my code, when i put this lines: recsize = sizeof(p1); fseek(fp,-recsize,SEEK_CUR); fwrite(&p1,sizeof(p1),1,fp); getch(); The file was saved with...
20
by: ericunfuk | last post by:
If fseek() always clears EOF, is there a way for me to fread() from an offset of a file and still be able to detect EOF?i.e. withouting using fseek(). I also need to seek to an offset in the file...
1
isladogs
by: isladogs | last post by:
The next online meeting of the Access Europe User Group will be on Wednesday 6 Dec 2023 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, Mike...
0
by: veera ravala | last post by:
ServiceNow is a powerful cloud-based platform that offers a wide range of services to help organizations manage their workflows, operations, and IT services more efficiently. At its core, ServiceNow...
0
by: VivesProcSPL | last post by:
Obviously, one of the original purposes of SQL is to make data query processing easy. The language uses many English-like terms and syntax in an effort to make it easy to learn, particularly for...
3
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 3 Jan 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). For other local times, please check World Time Buddy In...
0
by: mar23 | last post by:
Here's the situation. I have a form called frmDiceInventory with subform called subfrmDice. The subform's control source is linked to a query called qryDiceInventory. I've been trying to pick up the...
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 7 Feb 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:30 (7.30PM). In this month's session, the creator of the excellent VBE...
0
by: stefan129 | last post by:
Hey forum members, I'm exploring options for SSL certificates for multiple domains. Has anyone had experience with multi-domain SSL certificates? Any recommendations on reliable providers or specific...
0
Git
by: egorbl4 | last post by:
Скачал я git, хотел начать настройку, а там вылезло вот это Что это? Что мне с этим делать? ...
0
by: MeoLessi9 | last post by:
I have VirtualBox installed on Windows 11 and now I would like to install Kali on a virtual machine. However, on the official website, I see two options: "Installer images" and "Virtual machines"....

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.