mkdir() won't do it for me

[MikeC]

Good People,

I'm writing a backup utility that uses a chdir() to go into the source
directory (in which the files reside that I want to back up), so I don't
want to use chdir() to get into the target directory (where the backup
copies will be kept, on another drive). I can successfully test whether the
target directory exists or not using findfirst(), but if it doesn't, I
wanted to create it using mkdir(), but it doesn't like the path I'm using.

mkdir("newdirectory", S_IWUSR); // this works OK, and appends newdirectory
to the current path

mkdir("F:\\myfolder\\dumps", S_IWUSR); // does not work.

Incidentally, I use DJGPP, and S_IWUSR apparently makes the directory
read/write. If it is omitted, the directory is read-only.

I know that I could chdir() to the other disk then build up the path bit by
bit, but is there a more streamlined way?

Many thanks,

MikeC

--
Mental decryption required to bamboozle spam robots:

mike_best$ntlworld*com
$ = @
* = dot

 

[Richard Heathfield]

MikeC said:

Good People,

I'm writing a backup utility that uses a chdir() to go into the source
directory (in which the files reside that I want to back up), so I don't
want to use chdir() to get into the target directory (where the backup
copies will be kept, on another drive). I can successfully test whether
the target directory exists or not using findfirst(), but if it doesn't, I
wanted to create it using mkdir(), but it doesn't like the path I'm using.

mkdir("newdirectory", S_IWUSR); // this works OK, and appends
newdirectory to the current path

mkdir("F:\\myfolder\\dumps", S_IWUSR); // does not work.

Strange as it may sound, this isn't actually a question about C. Rather,
it's a question about your operating system. mkdir()'s behaviour is
governed not by the C language definition (which doesn't even mention it)
but by your implementation. So you'll want to be asking about it in a
Windows or MS-DOS programming group.

Just a thought, though - does myfolder exist? If not, that could be your
problem. You might not be able to create \a\b without first creating \a.

Anyway, I recommend comp.os.msdos.programmer or
comp.os.ms-windows.programmer.win32 as your next port of call.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.

 

[Bill Reid]

MikeC said:

You don't need to use chdir() for either directory, riiiiiiiiight?
findfirst() or opendir()...

Strange as it may sound, this isn't actually a question about C. Rather,
it's a question about your operating system. mkdir()'s behaviour is
governed not by the C language definition (which doesn't even mention it)
but by your implementation. So you'll want to be asking about it in a
Windows or MS-DOS programming group.

Just a thought, though - does myfolder exist? If not, that could be your
problem. You might not be able to create \a\b without first creating \a.

Anyway, I recommend comp.os.msdos.programmer or
comp.os.ms-windows.programmer.win32 as your next port of call.

Ah, horsefeathers...

I think this might help (I think this is all at least POSIX-compliant,
close enough for real-world work on non-embedded systems):

#include <stdio.h> /* required to breathe */
#include <stdlib.h> /* required to breathe for non-Unix */
#include <string.h> /* required to manipulate text */
#include <dir.h> /* required to make directories */
#include <dirent.h> /* required to scan data directories */

DIR *directory; /* directory pointer */
char path_directories[512];

unsigned directory_exists(char *target_directory) {

/* try to open the directory, return FALSE on failure */
if((directory=opendir(target_directory))==NULL)
return FALSE;

/* if we could open it, close it and return TRUE */
else {
closedir(directory);
return TRUE;
}
}

/* recursively creates all the needed file path directories */
unsigned make_file_path_dirs(char *file_path) {
unsigned dir_num=count_file_path_dirs(file_path);
unsigned dirs_needed=0,needed_dir=0,dirs_made=0;
char *search_ptr;

strcpy(path_directories,file_path);

while((search_ptr=strrchr(path_directories,'\\'))!=NULL) {

*search_ptr=NUL;

if(!directory_exists(path_directories)) dirs_needed++;

else {
needed_dir=dir_num;
break;
}

dir_num--;
}

if(dirs_needed>0) {

printf("\nFile path requires %i directories",dirs_needed);
printf("\nMaking directories: ");

strcpy(path_directories,file_path);
search_ptr=path_directories;

dir_num=0;
while((search_ptr=strchr(search_ptr,'\\'))!=NULL) {

if(dir_num==needed_dir) {

*search_ptr=NUL;

printf("\n %s",path_directories);

if(mkdir(path_directories)!=SUCCESS) {
printf("\n FAILED TO MAKE DIRECTORY!!!");
break;
}

*search_ptr='\\';
dirs_made++;
needed_dir++;
}

search_ptr++;
dir_num++;
}

if(dirs_made<dirs_needed) {

printf("\nCouldn't make all the required directories");
dirs_made=0;
}
}

else printf("\nNo directories required");

return dirs_made;
}

Anytime you want to write to a full file path or just make sure a
directory path exists, call make_file_path_dirs(char *file_path),
and bingo!, you are assured that your file/directory path is
copacetic...

 

[CBFalconer]

.... snip ...

mkdir("newdirectory", S_IWUSR); // this works OK, and appends
newdirectory to the current path

mkdir("F:\\myfolder\\dumps", S_IWUSR); // does not work.

Incidentally, I use DJGPP, and S_IWUSR apparently makes the
directory read/write. If it is omitted, the directory is
read-only.

I know that I could chdir() to the other disk then build up the
path bit by bit, but is there a more streamlined way?

Yes, by asking on comp.os.msdos.djgpp, where this is topical, and
you are likely to find someone who knows the appropriate answer.

 

[CBFalconer]

.... snip ...

I think this might help (I think this is all at least POSIX-compliant,
close enough for real-world work on non-embedded systems):

It is not helpful to post off-topic answers to off-topic queries,
when a simple redirection to an appropriate newsgroup will get the
OP the data he needs. It also encourages the asking of such
off-topic questions here.

 

[Richard Heathfield]

Bill Reid said:

Ah, horsefeathers...

....would at least have the merit of being portable.

I think this might help

<system-specific solution snipped>

Unlikely, since he's not using a POSIX-conforming implementation AFAIK.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.

 

[MikeC]

Folks,

I'm sorry if I asked this in the wrong group, and I agree with the sentiment
that off-group articles are not helpful - when looking at technical groups,
I have even seen such off-beat topics as celebrity sex films - not helpful
at all!!

However, that said, I really appreciate Richard Heathfield's gentlemanly
suggestion that my question would be better suited to another forum (DJGPP
in this case), and Bill Reid's offer of a considered solution to my problem.
I'll give it a go later today, Bill.

Thanks again to all,

MikeC.

 

[Kenny McCormack]

It is not helpful to post off-topic answers to off-topic queries,
when a simple redirection to an appropriate newsgroup will get the
OP the data he needs. It also encourages the asking of such
off-topic questions here.

You people need to get a grip.

 

[Bill Reid]

You people need to get a grip.

Or loosen it!

 

[Bill Reid]

Bill Reid said:

...would at least have the merit of being portable.

Please try comp.horsefeathers...

<system-specific solution snipped>

Can't say for sure right now just how many systems the "solution"
would work on, but I'm pretty sure it's more than one (and probably
more than 50, admittedly with some tweaks), therefore is not
"system-specific", riiiiiiiiiiight?

Unlikely, since he's not using a POSIX-conforming implementation AFAIK.

Can't say for sure right now, but I doubt there's any such thing as
a "POSIX-conforming implementation" in the anal-restrictive sense
anywhere on the face of the planet. Of course, that is also true of
an "ANSI C-conforming" implementation...

I actually have a hard-copy bound version of the POSIX standard
here, but only because I fished it out of the trash of "Unix house" I
worked at...the problem with the ANSI C standard appears to be
that even fewer people ever bothered to buy it in the first place, only
to throw it away as useless junk two months later...

When somebody posts a question with the term "mkdir()" in the
subject, as a PRACTICAL matter the actual answer is not actually
STRICTLY "POSIX-compliant", but, let us say, "derived from
Unix/POSIX and largely a 'work-alike' and most importantly
WIDELY USED ON MANY DIFFERENT 'SYSTEMS'
AND 'IMPLEMENTATIONS'".

Try to think logically: "mkdir()" is NOT specific to "DJGPP" (whatever
the holy god-forsaken hell that is). Interestingly enough, the SPECIFIC
"implementation" of "mkdir()" he mentions is closer to "POSIX" and
"Unix" than what I use to develop for Windows, because it takes
a "permissions" argument, though decidedly NOT the "Unix" argument...

So is "mkdir()" a "DJGPP" topic, a "C" topic, a "MS-DOS" topic,
a "Windows" topic, a "Linux" topic, a "Unix" topic, or what? And when
you figure that out, please tell me if a "socket" is a "Unix" topic
(as is so often asserted here) or a "Microsoft" topic (well, "winsock"
is)...

As a practical matter, the way people work who actually program
in the "C programming language" is to compile "foreign" code, count
the errors, check their documentation for missing functions/headers,
and make INTELLIGENT decisions from there...but of course,
that's all covered in alt.real-life...

 

[Kenny McCormack]

Or loosen it!

Well put.

(Of course, they won't get it)

 

[Flash Gordon]

Please try comp.horsefeathers...
Can't say for sure right now just how many systems the "solution"
would work on, but I'm pretty sure it's more than one (and probably
more than 50, admittedly with some tweaks), therefore is not
"system-specific", riiiiiiiiiiight?

It does not work on all the systems I have programmed so it certainly is
specific to a selection of systems not general to all systems.

Can't say for sure right now, but I doubt there's any such thing as
a "POSIX-conforming implementation" in the anal-restrictive sense
anywhere on the face of the planet. Of course, that is also true of
an "ANSI C-conforming" implementation...

I've no idea how many implementations claim POSIX compliance, nor how
many actually achieve it (modulo bugs). However, I do know that many
compilers, when correctly prodded, are compliant to a version of the ISO
C standard apart from the odd bug.

I actually have a hard-copy bound version of the POSIX standard
here, but only because I fished it out of the trash of "Unix house" I
worked at...the problem with the ANSI C standard appears to be
that even fewer people ever bothered to buy it in the first place, only
to throw it away as useless junk two months later...

Well, I find reference to a (draft of) the C standard useful sometimes.

When somebody posts a question with the term "mkdir()" in the
subject, as a PRACTICAL matter the actual answer is not actually
STRICTLY "POSIX-compliant", but, let us say, "derived from
Unix/POSIX and largely a 'work-alike' and most importantly
WIDELY USED ON MANY DIFFERENT 'SYSTEMS'
AND 'IMPLEMENTATIONS'".

Even if the mkdir takes a different number of arguments or they mean
completely different things?

Try to think logically: "mkdir()" is NOT specific to "DJGPP" (whatever
the holy god-forsaken hell that is). Interestingly enough, the SPECIFIC
"implementation" of "mkdir()" he mentions is closer to "POSIX" and
"Unix" than what I use to develop for Windows, because it takes
a "permissions" argument, though decidedly NOT the "Unix" argument...

If, as you claim in this post it is neither the same as the Unix version
nor the Windows version then very probably it *is* specific to DJPP.

So is "mkdir()" a "DJGPP" topic, a "C" topic, a "MS-DOS" topic,
a "Windows" topic, a "Linux" topic, a "Unix" topic, or what?

Depends on the version of mkdir being used. Which is one reason why it
is not topical here.

> And when
you figure that out, please tell me if a "socket" is a "Unix" topic
(as is so often asserted here) or a "Microsoft" topic (well, "winsock"
is)...

Actually, it could sensibly be argued that it is a networking topic and
there are networking groups.

As a practical matter, the way people work who actually program
in the "C programming language" is to compile "foreign" code, count
the errors, check their documentation for missing functions/headers,
and make INTELLIGENT decisions from there...but of course,
that's all covered in alt.real-life...

More sensible people review the code to find out what areas are standard
and will not need changing and what areas are system specific (even if
specific to a number of systems) and this group will help with that. I
consider questions like, "is such and such standard?" to be topical
here. I also consider the follow up questions of, "well, is there an
alternative that is standard, and if so what is it?" to be topical.

Also, it is possible to write vast amounts of code that is completely
standard C although you often also need a small amount of non-standard
(or different standard) code, and here we deal with that vast quantity
of standard code. I just wish that more people stuck to standard C where
extensions are not needed, it would make my life a lot easier.

 

[Chris Torek]

I think this might help (I think this is all at least POSIX-compliant,
close enough for real-world work on non-embedded systems):

No, because (at least):

while((search_ptr=strrchr(path_directories,'\\'))!=NULL) {

.... the POSIX path-separator character is slash ('/'), not backslash.

(There may be other problems, but this was the one that sprang right
out.)

 

[Bill Reid]

No, because (at least):


... the POSIX path-separator character is slash ('/'), not backslash.

Absolutely correct, but I believe that you can use '/' for what the
OP was working on and have it be portable to a very large majority
of all the general-purpose computer systems manufactured after
1990 (unfortunately, probably not the one I'm typing this on without
another "tweak")...

I did follow up and note that my definition of "POSIX-compliant"
isn't so much strict compatibility but rather just "sort of looks like
POSIX"...I don't know how that could possibly cause confusion...

(There may be other problems, but this was the one that sprang right
out.)

Also I noted the difference in the number of arguments to "mkdir()",
and the specifics of the "permissions" argument...other than that, and
probably a bunch of other stuff, it's totally POSIX-compliant! Who
knew MS-DOS was actually a Unix system!

 

[Bill Reid]

It does not work on all the systems I have programmed so it certainly is
specific to a selection of systems not general to all systems.

Nice try...well, not really, I give that a "4" on the Dodge-O-Meter...

I've no idea how many implementations claim POSIX compliance, nor how
many actually achieve it (modulo bugs). However, I do know that many
compilers, when correctly prodded, are compliant to a version of the ISO
C standard apart from the odd bug.

I very carefully (and sneakily) used the term "anal-restrictive" as opposed
to the more common term "anal-retentive"...as part of the "standards wars"
in Unix in years past there was at least one period where there was
a certain effort made to conform to POSIX, but you can be certain that
none of the systems CONFINED their functionality ENTIRELY to what
was in the POSIX standard...

Likewise, to the best of my knowledge and belief all the parts of the
compiler I used to compile the code I presented are absolutely conforming
to the ANSI C (90?) standard, except it also contains a whole bunch
of other stuff, including some 99 (?), "special extensions", "even more
special extensions that prove what geniuses we are", and of course, it's
actually a C++ compiler, but a lot of it is actually Pascal, to further
prove
what geniuses they were...

By comparison, just accepting mkdir() as a fact of a "C" programmer's
life is pretty benign, wouldn't you say?

Well, I find reference to a (draft of) the C standard useful sometimes.

Well, as far as later ANSI C standards (99?) are concerned, didn't
they wind up in the trash bin pretty much the day they were printed?
But yeah, I picked one up out of the trash and do look at it occasionally...

Even if the mkdir takes a different number of arguments or they mean
completely different things?

Well, yeah. It's the basic idea that counts, because mkdir() in all cases
takes a file path and makes a directory.

What the hell else are you going to do to make a directory on a system
that uses directories? Squat down like a baby in your own baby poop
and squall endlessly about "IT'S NOT PORTABLE MOMMY!!!", or
just "man up" and change the arguments to mkdir() to match your
system?

If, as you claim in this post it is neither the same as the Unix version
nor the Windows version then very probably it *is* specific to DJPP.

Unfortunately, this nonsense forced me to actually look at what
"DJGPP" actually is, and I almost threw up. Ironic, really, but trust
me, there's NOTHING "specific" about it, and of course, the OP's
problem almost certainly has NOTHING to do with a specific
"DJGPP" problem (if it is, it's most like a "Java problem" where the
program doesn't run right on differing Unix X-window managers
even though they use the same X intrinsics)...

Depends on the version of mkdir being used. Which is one reason why it
is not topical here.

OK, one of the choices was "C" and the OP dude was using a "C" version
of mkdir() (!) so I guess it IS on topic here! Done and done!

Actually, it could sensibly be argued that it is a networking topic and
there are networking groups.

Yes, but you do have to get increasingly granular because as a
"networking topic" it really doesn't have anything to do at all with any
actual networking protocols! It's just a particular low-level software
methodology for sending and receiving data that comes over a network
connection...conceptually, sockets work identically in both Windows
and Unix (Linux et. al.) systems.

If you're going to re-direct, it's actually something like
comp.programming.<system>.networking.sockets,
but most of the time, it's really just a higher-level networking
library implementation question, so the guy is just gonna
get bounced back to a protocol group, then to languages
group, back to the sockets group (which is a dead group
in the first place because there's really nothing to discuss)...

Really, the take-away lesson is that Usenet is only good
for political flame wars and race-baiting, which are ALWAYS
on-topic...

More sensible people

read: "sloooooow-working"?

review the code to find out what areas are standard

"standard" with what? If it's the "ANSI C standard" in the
"anal-restrictive" sense, then generally very little of it is "standard"
and we might as well just start squatting in the baby poop...

and will not need changing and what areas are system specific (even if
specific to a number of systems)

I dunno...I really think it boils down to some type of existing code
and library base where you "work". If you've seen and used mkdir()
before, you know you've got it, you're 90% done already...if not,
you're gonna find out very quickly in any event.

There's also something called "reading the labels on the package"
which is where "standards" are actually useful. If it says "ANSI C"
and "POSIX" on the label, and you know what those are and
what you have, again, you're 90% done already...too bad that
I've met several VPs of Software Development who couldn't handle
that simple task...

and this group will help with that. I
consider questions like, "is such and such standard?" to be topical
here. I also consider the follow up questions of, "well, is there an
alternative that is standard, and if so what is it?" to be topical.

So, the statement, "mkdir() is kind of a standard 'C' function for
making a directory, originally used in Unix" IS topical...whew, what
a relief...

Also, it is possible to write vast amounts of code that is completely
standard C although you often also need a small amount of non-standard
(or different standard) code, and here we deal with that vast quantity
of standard code.

Review carefully any and all of the code I post and note that a
large quantity of it is "standard" by your "restrictive" definition, but
if you want to get REALLY restrictive about it "printf()" isn't REALLY
a part of the "C" programming language, and neither is just about
everything else...

I just wish that more people stuck to standard C where
extensions are not needed, it would make my life a lot easier.

Absolutely, why re-invent the wheel? But if man had "standardized"
the wheel 6,000 years ago, we wouldn't have the "extension" of the
jet engine, and then what would happen to your frequent flyer miles?

 

[Keith Thompson]

Or loosen it!

Bill, please don't feed the troll.

 

[Kenny McCormack]

Bill, please don't feed the troll.

Keith, Keith, Keith. You are such a girl.
It is just hard to imagine someone who's life is so empty.

 

[Flash Gordon]

Well, yeah. It's the basic idea that counts, because mkdir() in all cases
takes a file path and makes a directory.

Have you used *all* current and future* implementations then? No,
thought not.

What the hell else are you going to do to make a directory on a system
that uses directories?

I might use CreateDirectory or whatever other non-standard function is
provided.

> Squat down like a baby in your own baby poop
and squall endlessly about "IT'S NOT PORTABLE MOMMY!!!", or
just "man up" and change the arguments to mkdir() to match your
system?

I have not said not to use it just that it is not topical here. If you
don't like the focus of this group, tough.

read: "sloooooow-working"?

No, I mean professionals who want to provide something that will work
and do it in a predictable timescale.

"standard" with what? If it's the "ANSI C standard" in the
"anal-restrictive" sense, then generally very little of it is "standard"
and we might as well just start squatting in the baby poop...

You obviously don't know how to write C properly. If you did you would
know that 90% of most projects can be written in strict C90. Then, that
90% does not need to be changed when porting.

I dunno...I really think it boils down to some type of existing code
and library base where you "work". If you've seen and used mkdir()
before, you know you've got it, you're 90% done already...if not,
you're gonna find out very quickly in any event.

Unless mkdir or some other non-standard code you are using behaves in s
subtly different manner so that normally it will work but in some
situations it will fail.

There's also something called "reading the labels on the package"
which is where "standards" are actually useful. If it says "ANSI C"
and "POSIX" on the label, and you know what those are and
what you have, again, you're 90% done already...too bad that
I've met several VPs of Software Development who couldn't handle
that simple task...

So educate them.

So, the statement, "mkdir() is kind of a standard 'C' function for
making a directory, originally used in Unix" IS topical...whew, what
a relief...

Show me the reference in the C standard. I'll save you the trouble,
there isn't one, so it is not standard C and not topical.

Review carefully any and all of the code I post and note that a
large quantity of it is "standard" by your "restrictive" definition, but
if you want to get REALLY restrictive about it "printf()" isn't REALLY
a part of the "C" programming language, and neither is just about
everything else...

You are showing your ignorance again. The printf standard is right there
in the C standard with clearly defined behaviour.

Absolutely, why re-invent the wheel? But if man had "standardized"
the wheel 6,000 years ago, we wouldn't have the "extension" of the
jet engine, and then what would happen to your frequent flyer miles?

The wheel being standardised would have no impact on the development of
the jet engine. C being standardised does not prevent extensions being
provided for things not covered by the C standard, in fact the C
standard specifically allows it.

If you want to argue that the focus of this group be changed at least
first learn what the focus is and what is covered by the C standard and
then get your facts right in your post. You might find these links helpful
http://clc-wiki.net/wiki/C_community:comp.lang.c:Portability_attitude
http://clc-wiki.net/wiki/intro_to_clc

 

[Martijn]

[the usual] Or loosen it!

Bill, please don't feed the troll.

Blaming the kettle...

 

[Bill Reid]

[the usual]

Or loosen it!

Bill, please don't feed the troll.

Which one?

Or did I just do it again?