Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Create hidden folder?

Status
Not open for further replies.

mbh27

Programmer
Jun 15, 2004
23
GB
Is it possible to create a hidden folder from from within VFP? I can't see that MKDIR offers the chance to set attributes.
 
Gregory Adam fromUT:
Code:
This may help

#define	TRUE	.T.
#define	FALSE	.F.
*--------------------------------------------------------------------------
#define INVALID_FILE_ATTRIBUTES		(-1)

#define	FILE_ATTRIBUTE_READONLY		0x00000001
#define	FILE_ATTRIBUTE_HIDDEN		0x00000002
#define	FILE_ATTRIBUTE_SYSTEM		0x00000004
#define	FILE_ATTRIBUTE_DIRECTORY		0x00000010
#define	FILE_ATTRIBUTE_ARCHIVE		0x00000020
#define	FILE_ATTRIBUTE_ENCRYPTED		0x00000040
#define	FILE_ATTRIBUTE_NORMAL		0x00000080
#define	FILE_ATTRIBUTE_TEMPORARY		0x00000100
#define	FILE_ATTRIBUTE_SPARSE_FILE		0x00000200
#define	FILE_ATTRIBUTE_REPARSE_POINT	0x00000400
#define	FILE_ATTRIBUTE_COMPRESSED		0x00000800
#define	FILE_ATTRIBUTE_OFFLINE		0x00001000
#define	FILE_ATTRIBUTE_NOT_CONTENT_INDEXED	0x00002000

declare Integer GetFileAttributes in win32api string @
declare Integer SetFileAttributes in win32api string @, Integer

function FileResetReadOnly(FileName)
	local fa
	fa = GetFileAttributes(@m.FileName)
	
	if( m.fa == INVALID_FILE_ATTRIBUTES )
		return FALSE
	endif
	
	if( empty(bitand(m.fa, FILE_ATTRIBUTE_READONLY)) ) && file was not readonly
		return FALSE
	endif
	
	fa = bitand(m.fa, bitnot(FILE_ATTRIBUTE_READONLY))
	
	if( empty(SetFileAttributes(@m.FileName, m.fa)) )
		return FALSE
	endif
	
endfunc
*--------------------------------------------------------------------------
function FileSetReadOnly(FileName)
	local fa
	fa = GetFileAttributes(@m.FileName)
	
	if( m.fa == INVALID_FILE_ATTRIBUTES )
		return FALSE
	endif
	
	fa = bitor(m.fa, FILE_ATTRIBUTE_READONLY)
	
	if( empty(SetFileAttributes(@m.FileName, m.fa)) )
		return FALSE
	endif
	
endfunc

But WHY?


Borislav Borissov
VFP9 SP2, SQL Server 2000/2005.
 
Boris,

This is for File attributes - what about directory?
 
What's the difference?

Borislav Borissov
VFP9 SP2, SQL Server 2000/2005.
 
Thanks for your input bborissov. I'll have a look at this. What I need it for is to create a duplicate copy of a text file somewhere out of the way (in a hidden folder). This is really for audit purposes. A user might be able to edit the normal text file output from the VFP app (though this may be very unlikely), but we'd always then have a copy of the original (which is even more unlikely to have been 'doctored'). The duplicate file (hidden and read-only) in the hidden folder will be created out of sight or knowledge of the user. I'd like the app itself, though, to create the hidden folder in the first place.
 
Sure:
Code:
#define    TRUE    .T.
#define    FALSE    .F.
*--------------------------------------------------------------------------
#define INVALID_FILE_ATTRIBUTES        (-1)

#define    FILE_ATTRIBUTE_READONLY        0x00000001
#define    FILE_ATTRIBUTE_HIDDEN        0x00000002
#define    FILE_ATTRIBUTE_SYSTEM        0x00000004
#define    FILE_ATTRIBUTE_DIRECTORY        0x00000010
#define    FILE_ATTRIBUTE_ARCHIVE        0x00000020
#define    FILE_ATTRIBUTE_ENCRYPTED        0x00000040
#define    FILE_ATTRIBUTE_NORMAL        0x00000080
#define    FILE_ATTRIBUTE_TEMPORARY        0x00000100
#define    FILE_ATTRIBUTE_SPARSE_FILE        0x00000200
#define    FILE_ATTRIBUTE_REPARSE_POINT    0x00000400
#define    FILE_ATTRIBUTE_COMPRESSED        0x00000800
#define    FILE_ATTRIBUTE_OFFLINE        0x00001000
#define    FILE_ATTRIBUTE_NOT_CONTENT_INDEXED    0x00002000

declare Integer GetFileAttributes in win32api string @
declare Integer SetFileAttributes in win32api string @, Integer


? FileSetReadOnly([c:\test]) && Just make sure you have C:\TEST folder


function FileResetReadOnly(FileName)
    local fa
    fa = GetFileAttributes(@m.FileName)
    
    if( m.fa == INVALID_FILE_ATTRIBUTES )
        return FALSE
    endif
    
    if( empty(bitand(m.fa, FILE_ATTRIBUTE_READONLY)) ) && file was not readonly
        return FALSE
    endif
    
    fa = bitand(m.fa, bitnot(FILE_ATTRIBUTE_READONLY))
    
    if( empty(SetFileAttributes(@m.FileName, m.fa)) )
        return FALSE
    endif
    
endfunc
*--------------------------------------------------------------------------
function FileSetReadOnly(FileName)
    local fa
    fa = GetFileAttributes(@m.FileName)
    
    if( m.fa == INVALID_FILE_ATTRIBUTES )
        return FALSE
    endif
    
    fa = bitor(m.fa, FILE_ATTRIBUTE_HIDDEN)
    
    if( empty(SetFileAttributes(@m.FileName, m.fa)) )
        return FALSE
    endif
    
endfunc

Borislav Borissov
VFP9 SP2, SQL Server 2000/2005.
 
I'm always impressed by people who can use the API so fluently but if you are allowed to use the Windows Scripting Host then:

Code:
fso= CREATEOBJECT  ('Scripting.FileSystemObject')
fld=fso.CreateFolder("Dummy")
fld.Attributes = fld.Attributes + 2

will do the job. The CreateFolder method creates a folder with Attributes=16 (indicating that it is indeed a folder) and adding 2 sets the Hidden bit. Adding 1 would set the ReadOnly bit.

Geoff Franklin
 
Hi Geoff,

better use Bitset to set bits. As +2 in case of 18 would not set the attribute Bit, but unset it and set Bits 4 and 2 valued 16 and 4.

To set the Bit valued 2, you determine N in 2^n=bitvalue, N=1 results in 2^1=2, so 1 is the bit number. Then use Bitset(fld.Attributes,1) to set that bit 1. If it's already set you don't change the value by it and don't set other bits you don't want to set.

Bye, Olaf.
 
OK - now a variation on a theme. What if I have a file 'A.TXT' in folder X and I want to make a copy of this in folder Y (which already exists) but I want the copy to be ReadOnly and Hidden. Any ideas on the neatest way to do this?
 
I can now achieve what I want using 'scripting.FileSystemObject', but is the file SCRRUN.DLL (which I understand is required) always likely to be available on a (client's) Windows system?
 
Some administrators will disable the Windows Scripting Host because it can pose a security risk. If you're writing this application for commercial distribution then forget everything I've said and use the Windows API. If it's just for a single client then ask them about their security policy.

Geoff Franklin
 
Geoff,

You're having a false assumption.

'Scripting.FileSystemObject' is a COM helper object, and COM objects or classes are registered and cannot be switched off. So even if scripting is switched off this object will be there and is instanciable and usable. 'Scripting.FileSystemObject' is just the filesystem COM class of scripting, it is not scripting itself. It will work no matter if you switch scripting off or not.

Try it out yourself:
create the registry key
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows Script Host\Settings\Enabled

as a DWORD and set/keep it 0 to disable WSH.
Tht's according to Microsoft and they should know how to turn WSH off:
o = CreateObject("Scripting.FilesystemObject") still works. Why should it stop working? It's not scripting. Scripting is running vbs scripts via cscript.exe or wscript.exe. These two are disabled, nothing else.

Bye, Olaf.
 
It might be that I'm remembering wrong Olaf but I'm sure I had to rewrite a fso utility for one client because they had disabled it.

I looked at the Microsoft page you quoted but then found that Microsoft TechNet do give instructions for disabling the File System Object:
Geoff Franklin
 
Hi Geoff,

okay, but that's different from disabling WSH - Windows Script Host, and I wouldn't also call this disabling FSO, it's unregistering FSO, therefore it's more like uninstalling a windows feature.

I don't see how FSO is a safety risc, as it just offers functionality you still have without it via alternatives, eg copying or creating files can be done completely without any OS COM object or API call with FOPEN, FWRITE etc.

Therefore I see unregistering FSO as a false step. If you want security of your files, you better have decent access restrictions on the folder and network level, just disabling such a helper COM object doesn't disable writing at all, it just disables to write via the FSO class, so it just is an annoyance to programmers that want to make use of a higher level way of handling files than with low level file functions.

I understand this can be a step to sucessfully disable tools that rely on it, but it's in general not a step to higher security.

Bye, Olaf.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top