Very Computer

We are now porting a program from linux to solaris. In the linux
version, i wrote a function to remove a dir recursively, the code is
showed as follows:

void remove_dir(char* sz_dir)
{
        char subname[256];
        DIR *pdir = NULL;
        struct dirent *pdirent = NULL;

        pdir = opendir(sz_dir);
        if (pdir) {
                //printf("into dir %s\n", sz_dir);
                while ((pdirent = readdir(pdir)) != NULL) {
                        //printf("type is %d\n", pdirent->d_type);
                        //printf("name is %s\n", pdirent->d_name);
                        if (pdirent->d_type == 8) {
                                sprintf(subname, "%s/%s", sz_dir, pdirent->d_name);
                                remove(subname);
                        }

                        if (pdirent->d_type == 4
                                && strcmp(pdirent->d_name, ".") != 0
                                && strcmp(pdirent->d_name, "..") != 0) {
                                sprintf(subname, "%s/%s", sz_dir, pdirent->d_name);
                                remove_dir(subname);
                        }
                }
                closedir(pdir);
                remove(sz_dir);
        }
        else {
                printf("Error in reading %s : %s\n", sz_dir, strerror(errno));
        }

Quote:}

I found the struct dirent in solaris doesn't have field d_type! I am
not familiar with solaris, so, please tell me how to remove a dir in
solaris, thanks a lot.

what's wrong with rm -r ?

--
The e-mail address in our reply-to line is reversed in an attempt to

Because the program is multi-threaded. It seems that the thread can't
call exec (or something like this) to run shell command.

d_type is nonstandard. If you write portable programs you shouldn't rely
on that, see
        http://www.opengroup.org/onlinepubs/009695399/basedefs/dirent.h.html

Quote:> I am not familiar with solaris, so, please tell me how to remove a dir in
> solaris, thanks a lot.

The same as you remove a directory in every other system: with the
rmdir(2) system call.

To check a given filename is really a directory use the stat(2) function.

--
Daniel

I don't know for sure what d_type means, but I guess you will have to
stat(2) the directory entry and evaluate the st_mode field. See mknod(2)
to find out how to do this.

HTH,
Tom

cleanly written programs don't use nonstandard field that are only
present on a single OS.

Check the POSIX standard on the web pages of the OpenGroup
for what is standard....

--



URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

The clean ans fast method to check for file vs. directory
is to first call rmdir(2) and if this returns ENOTDIR, call
unlink(2).

This method works since 25 years.

--



URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Nonsense!

It is perfectly safe to do system("rm -rf abc"), or even fork()/exec(),
in a multi-threaded program, for versions of Solaris >= 2.5.1 (I don't
know about previous versions).

        Cheers,
                Gary    B-)

--
______________________________________________________________________________
Armful of chairs: Something some people would not know
                   whether you were up them with or not
                                      - Barry Humphries

thank you all !
i will try them soon.

Apart from what others have mentioned already (nonstandard linux
extensions, use stat(2) instead) you probably should not use
readdir(3C) in a multi-threaded program in the first place. The man
page says:

   |  MT-Level                   |  readdir()    is     Unsafe;|
   |                             |  readdir_r() is Safe.       |

"MT" stands for "Multi-Thread"...

Also, the size of your 'sname'-array is risky, You'll probably want to
make that at least _XOPEN_PATH_MAX + 1 (and, needless to say (?!?) use
snprintf(3C) instead of sprintf(3C))

(Strictly speaking, the maximum path size depends on the underlying
filesystem and is to be queried through [f]pathconf(2) at run time. So
you'd have to malloc(3C) your buffer and whenever you descend one
level you would have to check if you're about to cross a file system
boundary and if so, reread the pathconf value and realloc(3C) your
buffer if it is too small. And don't forget to free() your buffer upon
all exits of the procedure, including error exits and check all the
return codes and to something sensible on failure. Isn't C programming
just fun...)

Generally, for portability, never use integer constants for values
that have symbolic definitions in the standard headers.

--
Stefan Jankowski
Sysadmin, University of Freiburg, CS Dpt.
s/spambucket//
s/dave\.null/${FORENAME}.${LASTNAME}/

Quote:> It is perfectly safe to do system("rm -rf abc"), or even
> fork()/exec(), in a multi-threaded program, for versions of Solaris >=
> 2.5.1 (I don't know about previous versions).

That is true *only* if all libraries/objects one links against have
implemented proper atfork handlers.

If they didn't, calling system() [or any other fork()ing function]
will likely result in random deadlocks.

The statement "it is perfectly safe to fork()" is definitely false
in the general case, where the quality of "other" code linked into
the process is unknown.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

Well, if you use third-party libraries of dubious functionality, that
replace system()/fork()/exec(), then you get _exactly_ what you deserve.

FWIW - there is MT code I have worked on that has been out there
commercially on Solaris (and HPUX, AIX, Tru64) since, oh, 2000, and it's
not had a "random deadlock" as a result of fork()/exec()/system()
problems.  And it does a _lot_ of fork()/exec()'s and system()'s.

It's had random deadlocks from other causes, usual bad programming,
losing track of which mutexes are held and so on, but none from
fork()/exec() or system().

It is also far from a trivial product, several multi-threaded binaries
running 8-12 threads, and one biggie that ran from 15 to 128, and as it
is a monitoring product, it has to run 24x7.

        Cheers,
                Gary    B-)

--
______________________________________________________________________________
Armful of chairs: Something some people would not know
                   whether you were up them with or not
                                      - Barry Humphries