No subject


Thu Mar 12 02:30:28 EDT 2009


I have the following

C:\test
C:\test\dir_1
C:\test\dir_2
C:\test\file_1.txt
C:\test\file_2.txt

This code produces the following output:

 char **rc =3D PHYSFS_enumerateFiles("test");	// pointing to c:\test
 char **i;
 int result;
=20
 for (i =3D rc; *i !=3D NULL; i++)
 {
         result =3D PHYSFS_isDirectory(*i);
//         if (result !=3D 0)
         logToFile("We've got dir [%s] - [ %i ].", *i, result);
 }
 PHYSFS_freeList(rc);   =20

Logfile output:

08:30:27 > We've got dir [dir_1] - [ 0 ].
08:30:27 > We've got dir [dir_2] - [ 0 ].
08:30:27 > We've got dir [file_1.txt] - [ 0 ].
08:30:27 > We've got dir [file_2.txt] - [ 0 ].

It is showing both files and directories - however, 'PHYSFS_isDirectory' is=
n't picking up the difference between a file and a directory.  It should be=
 returning a different result for the two.

I'm quite happy to walk the tree myself, but I need to know the difference =
between a file and a directory.  Chdir(file_1.txt) probably isn't the smart=
est thing to do :)

I was toying doing string searches for ('mp3') and then assuming everything=
 else is a directory - bad assumption for things list .txt or playlist file=
s.

Is 'PHYSFS_isDirectory' broken?

Thanks

-----Original Message-----
From: Tom Wilson [mailto:t.wilson at hazid.com]=20
Sent: Thursday, 16 December 2004 10:04 PM
To: physfs at icculus.org
Subject: Re: [physfs] Not finding any directories

Berry, David wrote:
>=20
> Hi
>=20
> I have the following code
>=20
> char **rc =3D PHYSFS_enumerateFiles("music");
>=20
>  char **i;



http://icculus.org/physfs/docs/html/physfs_8h.html#a29

I think the documentation for "PHYSFS_enumerateFiles" indicates that NO=20
directory names will be returned in the array.


 From the docs:

Matching directories are interpolated. That is, if "C:\mydir" is in the=20
search path and contains a directory "savegames" that contains "x.sav",=20
"y.sav", and "z.sav", and there is also a "C:\userdir" in the search=20
path that has a "savegames" subdirectory with "w.sav" [snip]

=2E..will print:

  * We've got [x.sav].
  * We've got [y.sav].
  * We've got [z.sav].
  * We've got [w.sav].

So, here you have in the search path
C:\mydir
C:\userdir

and the following files:

C:\mydir\savegames\x.sav
C:\mydir\savegames\y.sav
C:\mydir\savegames\z.sav
C:\userdir\savegames\w.sav

and it clearly isn't showing "savegames" or even ".", ".." in the list=20
which would of course exist on (some?) file systems.

I don't think this function is going to do what you need.  Perhaps you
could use playlists which indicate where the files are stored?

Also, another point is that the docs say:  "We only promise there will=20
be no duplicates"

so if you had

C:\foo\Ace of Base - All That She Wants.MP3
C:\myMp3s\Ace of Base - All That She Wants.MP3

I *think* you would only get one song returned, even though the two=20
files may be different remixes.  I haven't tested this though.

HTH

- Tom

>  for (i =3D rc; *i !=3D NULL; i++)
>=20
>  {
>=20
>         if (PHYSFS_isDirectory(*i) !=3D 0)
>=20
>           logToFile(" * We've got dir [%s].", *i);
>=20
>  }
>=20
> I have a directory tree full of music files, and I am attempting to find 
> out all the directories contained within.
>=20
> If I just log the string *i, I can see everything, files and directory 
> names - if I attempt to 'detect' a directory, I get nothing.
>=20
> Eg: Just printing out the output gets
>=20
> 23:27:47 >  * We've got dir [Ace of Base - All That She Wants.MP3].
>=20
> 23:27:47 >  * We've got dir [BEVERLY HILLS COP.MP3].
>=20
> 23:27:47 >  * We've got dir [CD 4].     =DF-- These are directories
>=20
> 23:27:47 >  * We've got dir [CD 5].     =DF--- This is a directory
>=20
> It's running on a XP box compiled with Bloodshed 4.9.9.1.
>=20
> Any idea on why I can't detect my directories - or does someone have=20
> some code to 'walk' a tree and display all the files contained within.  
> I'm writing a basic MP3 player - which you can point at your music store 
> and play everything.
>=20
> Thanks
>=20








More information about the physfs mailing list