FindFileFirst CreateDir

[D]

I'm a newbee doing my first file handler.
I noticed from experimentation running on XP home
that if you call CreateDirectory and the directory is
already in existence that it is not overwritten.
So I'm wondering if there is really any need for me
to call FindFileFirst to see if the directory exists before
I call CreateDirectory ?
Also with FindFileFirst the filedata structure holds
the return of the file/folder attribute. The include
files define a Directory attribute of a binary value of
10000 but a directory can have other attributes like
hidden system etc. which could add other bits set
besides the first bit of the Directory attribute. So....
wouldn't one need to bitwise & "and" the returned
FileAttributes from FindFileFirst with 10000 before
testing to see if it's a directory other than just
comparing it with the defined
DIRECTORY_ATTRIBUTE of bin 10000?

[R.Wieser]

D <NoMail@NoSpam> schreef in berichtnieuws bvjck...@enews1.newsguy.com...

Hello D,

> I'm a newbee doing my first file handler.

Well, a welcome to you than :-)

> I noticed from experimentation running on XP home
> that if you call CreateDirectory and the directory is
> already in existence that it is not overwritten.
> So I'm wondering if there is really any need for me
> to call FindFileFirst to see if the directory exists before
> I call CreateDirectory ?

Nope, not needed. But you could get an error back that will tell you of the
failed create-attempt (you *do* check for errors, don't you ?)

> Also with FindFileFirst the filedata structure holds
> the return of the file/folder attribute. The include
> files define a Directory attribute of a binary value of
> 10000 but a directory can have other attributes like
> hidden system etc. which could add other bits set
> besides the first bit of the Directory attribute. So....
> wouldn't one need to bitwise & "and" the returned
> FileAttributes from FindFileFirst with 10000 before
> testing to see if it's a directory other than just
> comparing it with the defined
> DIRECTORY_ATTRIBUTE of bin 10000?

No, and No.

[Remark : As I have no idea what language you're programming in, my answer
might not directly fit to your problem]

You're right that you should remove (mask-off) all bits that are not
relevant to what you want to know, before you check for what you really want
to know.

But masking-off non-relevant bits is an operation that itself results in
either status-flags being changed (relevant when you're using Assembly), or
that the result-value of the masking process is either zero, or non-zero
(relevant when using "high(er)-level" languages). This means that further
comparing with the bit-value itself is mostly not nessesary anymore.

Example :

TEST [Attributes],DIRECTORY_ATTRIBUTE ;-- Assembly-command

Zero-flag will be clear (non-zero) if the directory-bit was not set.

if (attributes and DIRECTORY_ATTRIBUTE ) then '-- (Visual-) Basic
command

Commands following the above line will be taken if the directory-bit is set,
as the AND-ing result is non-zero.

I hope this explains it a bit.

Regards,
Rudy Wieser

[D]

Thanks for the answer and to be more specific about
the language I'm using it's C, and I am concerned
that if I only compare the return as in,
if ((Filedata->FileAttributes) ==DIRECTORY_ATTRIBUTE )
and it is a directory but it's a system directory so the value
in Filedata->FileAttributes is not 10000 but rather something
like 10010 (can't remember exactly) then I'm not going to know
that it's a directory.

defined in include file
DIRECTORY_ATTRIBUTE = 10000

[Sten Westerback]

"D" <NoMail@NoSpam> wrote in message news:bvk49...@enews1.newsguy.com...

Use if ((Filedata->FileAttributes & DIRECTORY_ATTRIBUTE))!=0)
or if ((Filedata->FileAttributes &
DIRECTORY_ATTRIBUTE))==DIRECTORY_ATTRIBUTE).

Or you could check for folder existence by
FindFirstFile(... "folderpath\\foldername\\*.*" ..) if you know you
have access rights to the folder. This will at least give you
the "." and ".." files...

- Sten

[D]

Thanks.

[r_z_...@pen_fact.com]

For what it's worth, I use the following functions to check existence
of files and directories. I'm pretty sure they are more efficient than
using FindFirstFile.

I edited slightly, and my news client edited also (line wrap).

const LPCTSTR g_kPathDelStrW = _T( "\\" ); // File path
delimiter
//

--------------------------------------------------------------------
// Determine whether string argument is empty
inline BOOL PFSArgIsEmpty( LPCTSTR sIn )
{
#if ISDEBUG
// Debugger initializes memory to 0xcccccccc
LPCTSTR sC = reinterpret_cast<LPCTSTR>(0xcccccccc), // VC
6 debugger?
sE = reinterpret_cast<LPCTSTR>(0xeeeeeeee); //
BoundsChecker
// sO = reinterpret_cast<LPCTSTR>(-35); //
??
ASSERT( sIn != sC );
ASSERT( sIn != sE );
// ASSERT( sIn != sO );
#endif
return (sIn == NULL || sIn[0] == _T( '\0' ) );
} // PFSArgIsEmpty

//
--------------------------------------------------------------------
// PFFileGetAttrib
DWORD PFFileGetAttrib( LPCTSTR sPath, TCHAR cPathDel = g_kPathDelChar
)
{
ASSERT( !PFSArgIsEmpty( sPath ) );
size_t tLen = _tcslen( sPath ) - 1;
if (sPath[tLen] == cPathDel)
{
TCHAR sCopy[MAX_PATH + 1];
_tcscpy( sCopy, sPath );
sCopy[tLen] = TNULL;
return PFFileGetAttrib( sCopy, cPathDel );
}
return ::GetFileAttributes( sPath );

} // PFFileGetAttrib

// -----------------------------------------------
// PFFileExists
// Tested, successfully, with Windows CE 2.00 (HPC), 2.01
(Palm-size PC),
// 2.11 (HPC Pro and Palm-size PC 1.2), and Pocket CP.
// Tested successfully with Windows 95, Windows 98, Windows NT 4,
Windows 2000
// Tested using directories and "ordinary" files
// Tested using shares (where shares are supported).
inline BOOL PFFileExists( LPCTSTR sPath, TCHAR cPathDelChar =
g_kPathDelChar )
return (PFFileGetAttrib( sPath ) != BAD_FILE);

-----------------------------------------
To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).

Robert E. Zaret
PenFact, Inc.
500 Harrison Ave., Suite 3R
Boston, MA 02118
www.penfact.com