file.remove

[WillieLucas]

I'm trying to remove all files from a directory. Does file.remove support *.* file.remove("dir_path\*.*")
Thanks
Willie

[AaronBBrown]

RE: file.remove

What happens when you do it?

[CALocklin]

RE: file.remove

According to the Help file:
Erases a particular file, removing it from the disk. You must supply an existing Filename.

[AaronBBrown]

RE: file.remove

You can use file.remove() in conjunction with filefind.get_recurse() to get a list of all files in a directory, then loop through them and delete them.

[Selwyn Rabins]

RE: file.remove

here is how you could do it in just 2 lines of code:

files = filefind.get("c:\webvars1*.txt",0,"pn")
*for_each(x,file.remove(x),files)


(this removes all files in my c:\ folder that match the patter: c:\webvars1*.txt


if you examined files, you would have seen:
= c:\Webvars1.Txt
c:\Webvars10.Txt
c:\Webvars100.Txt
c:\Webvars101.Txt
c:\Webvars102.Txt
c:\Webvars103.Txt

[CALocklin]

RE: file.remove

With one exception - filefind.get() and filefind.get_recurse() still don't work for files with the Archive attribute turned off:

'All files in the target directory have all attributes turned off.
?filefind.get_recurse("H:\a5v5\_a5v5_std\logins","*.*")
= ""

?filefind.get_recurse("H:\a5v5\_a5v5_std\logins","*.*",FILE_FIND_NORMAL)
= ""

?filefind.get_recurse("H:\a5v5\_a5v5_std\logins","*.*",FILE_FIND_NOT_ARCHIVE)
= ""

?filefind.get_recurse("H:\a5v5\_a5v5_std\logins","*.*",FILE_FIND_NOT_DIRECTORY)
= ""

'Now I have reset all files to have the archive attribute set.
?filefind.get_recurse("H:\a5v5\_a5v5_std\logins","*.*")
= H:\a5v5\_a5v5_std\logins\Logins.adb
H:\a5v5\_a5v5_std\logins\Logins.Muf
H:\a5v5\_a5v5_std\logins\Logins.Alb
H:\a5v5\_a5v5_std\logins\Logins.Alm
H:\a5v5\_a5v5_std\logins\Logins.Alx
H:\a5v5\_a5v5_std\logins\Logins.Recent_Files
H:\a5v5\_a5v5_std\logins\App_Codes.Dbf
H:\a5v5\_a5v5_std\logins\App_Codes.Cdx
H:\a5v5\_a5v5_std\logins\App_Codes.Ddd
H:\a5v5\_a5v5_std\logins\App_Codes.Ddm
H:\a5v5\_a5v5_std\logins\App_Codes.Ddx
H:\a5v5\_a5v5_std\logins\Copy of App_Codes.Ddx
H:\a5v5\_a5v5_std\logins\Copy of App_Codes.Dbf
H:\a5v5\_a5v5_std\logins\Copy of App_Codes.Ddd
H:\a5v5\_a5v5_std\logins\Copy of App_Codes.Ddm
H:\a5v5\_a5v5_std\logins\Copy of App_Codes.Cdx
H:\a5v5\_a5v5_std\logins\_Doclogins.Dbf
H:\a5v5\_a5v5_std\logins\_Doclogins.Fpt
H:\a5v5\_a5v5_std\logins\_Doclogins.Cdx
H:\a5v5\_a5v5_std\logins\_Doclogins.Ddd
H:\a5v5\_a5v5_std\logins\_Doclogins.Ddm
H:\a5v5\_a5v5_std\logins\_Doclogins.Ddx
H:\a5v5\_a5v5_std\logins\Script_Usage.Txt
H:\a5v5\_a5v5_std\logins\Function_Usage.Txt
H:\a5v5\_a5v5_std\logins\Aims_Logins.Aex


Since the archive attribute is supposed to be used by backup routines to determine whether or not a file should be incluced in an incremental backup, the archive bit should be turned off whenever a regular backup routine is run.

[AaronBBrown]

RE: file.remove

>

While this sounds like a bug, the reality is that very few backup programs actually use the archive bit for a number of reasons.

[CALocklin]

RE: file.remove

Regardless of what the backup routines do, there are numerous files on my computer that do not have the archive bit set. Here's the results of checking my system:

C Drive - (1.8 gig used) - 503 files
D Drive - not used; only 6 meg available
E Drive - (1.8 gig used) - 2206 files
F Drive - (1.3 gig used) - 197 files
G Drive - not used; only 8 meg available
H Drive - (15.5 gig used) - 11,429 files

That makes 14,335 files on my computer that the Filefind functions can't see. I made no attempt to change anything prior to running this test except as noted in the next paragraph.

The H drive is primarily for data files - Alpha, Access, Approach, Word, Excel, Help editor files, etc. In most cases, the Alpha data files have had the archive bit specifically turned on because I am aware of the potential issue.

If anyone wants to check their own computer, go to the root directory in a DOS window and issue this command:
DIR /a-a /s

(For those not familiar with DOS, type DIR /? for an explanation of the command.)

If only working with data files that are listed in the control panel of the database, there are other ways to get all the file names. However, if there are tables that are used but not included in the 'official' list shown in the control panel, the archive bit must be on for Filefind to locate them. Also, any graphics files, text files, etc. must have the archive bit on if there is any need to locate them with a Filefind function. All of these situations have occurred for me in past applications. The Filefind hasn't caused any major problems yet because I'm aware of the issue but there is one application where the customer regularly runs a loop that executes a DOS command to reset all the attributes to avoid any potential problems. This loop results in a bunch of little DOS icons scrolling across their Windows Taskbar then disappearing - annoying but not a problem.

I tried using File.attributes_set() but that requires a specific filename and the only way to get the specific filename of unknown files (like graphics added by a user) is to use a Filefind function - classic Catch 22; you can't get there from here.

SPECIFIC SITUATIONS THAT CAN RESULT IN THE ARCHIVE BIT BEING 'OFF':
(not counting any backup routines that might still use it.)

Copying data from a CD will result in all attributes OFF except the Read-only bit which is always ON. The Read-only bit is a well known issue. Many users are now aware that they need to turn the Read-only bit off because they have already experienced the fear of "Oh no! My data is gone!" but most don't know about the issue of turning on the archive bit. For data files this is typically a short term issue that disappears as soon as the table is changed but there are often other files such as graphics and text files that may not be modified for a long time. And, if the user adds new graphics, such as a realtor adding new property photos from a CD, there is no way for the program to know they are there.

Files installed by an installation routine sometimes have the archive bit turned off. In some cases this may be because the original file had the bit turned off but, at least in the install routine I use, the install routine itself can be set to turn off all archive bits. I know that some installation programs I've run have installed files with the archive bit off.

[csda1]

RE: file.remove

Aaron,

Actually the bug doesn't list files when both the read-only and archive flags are clear at the same time. Any other variant (one or both) flags set, irrespective of System, Directory and Hidden flags settings works fine.

I reported this bug along time ago on the board in a thread with Selwyn in version 4.0 and 4.5

Regards,

Ira