f



How to copy a file to a file with a prefixed file name

I'm trying to write a program that will archive selected files to an
archive directory.  The files in the archive directory will have a
prefix in the format yyyymmdd-hhmmss-filename.ext.  So, if the file is
called "somefile.dat", then the filename in the archive directory
should be "20090522-164325-somefile.dat".  I'm using Clipper's COPY
FILE command to do the copy.  I can't figure out how to get the prefix
in front of the file name.  Creating the prefix string is no problem,
but I can't figure out how to tack that onto the front of the
filename.  If I could retrieve the name of the file into a character
variable then my problem would be solved but I can't figure out how to
do that.  I saw where I could get the name of a .dbf file but not of a
..txt or other type of file.  Any ideas?
0
none2847 (96)
5/22/2009 8:51:01 PM
comp.lang.clipper 3959 articles. 0 followers. Post Follow

20 Replies
1744 Views

Similar Articles

[PageSpeed] 59

Dear Scott Coffey:

On May 22, 1:51=A0pm, Scott Coffey <n...@noemail.com.invalid> wrote:
> I'm trying to write a program that will archive
> selected files to an archive directory.
....
> If I could retrieve the name of the file into
> a character variable then my problem would be
> solved but I can't figure out how to do that.
>=A0I saw where I could get the name of a .dbf
> file but not of a .txt or other type of file.
>=A0Any ideas?

How about retrieving it from the contents of directory()?
http://www.ousob.com/ng/53guide/ng38a9b.php

David A. Smith
0
dlzc1 (2365)
5/22/2009 9:29:42 PM
Scott

Clipper file functions don't handle long filenames very well (ie outside the 
8.3 convention)

CYA
Steve 


0
stevejqNO (62)
5/22/2009 11:44:57 PM
On 22 May 2009 15:51:01 -0500, Scott Coffey <none@noemail.com.invalid>
wrote:

>
>I'm trying to write a program that will archive selected files to an
>archive directory.  The files in the archive directory will have a
>prefix in the format yyyymmdd-hhmmss-filename.ext.  So, if the file is
>called "somefile.dat", then the filename in the archive directory
>should be "20090522-164325-somefile.dat".  I'm using Clipper's COPY
>FILE command to do the copy.  I can't figure out how to get the prefix
>in front of the file name.  Creating the prefix string is no problem,
>but I can't figure out how to tack that onto the front of the
>filename.  If I could retrieve the name of the file into a character
>variable then my problem would be solved but I can't figure out how to
>do that.  I saw where I could get the name of a .dbf file but not of a
>.txt or other type of file.  Any ideas?


Scott,

Unless you use the long name library, Clipper will not be able to
handle this directly because of standard DOS file naming rules.

Another trick would be to use a long name as the contents of a dbf
field and use a unique file name that is associated with your long
name text.


Regards,

Ross McKenzie
ValuSoft
Melbourne Australia

valusoft AT optusnet DOT com DOT au
0
5/23/2009 1:05:10 AM
In article  <ZNGRl.12923$y61.2726@news-server.bigpond.net.au>
           stevejqNO@bigpondSPAM.net.au "Stephen Quinn" writes:

> Scott
> 
> Clipper file functions don't handle long filenames very well (ie outside the 
> 8.3 convention)
> 
> CYA
> Steve 

Indeed.  Clipper will need some "help".

My first thought was Klas' LFN library though I'm not sure if 
COPY FILE will handle that internally.  And you didn't say 
whether you are using S87 or 5.x (and I've forgotten from your 
earlier posts); this lib only available for 5.x unless someone 
has ported it in the last few years.

You are talking LFN so I assume you're running on a Win32 of some 
flavour.  You could try using the system32 COPY command: get the 
name of the file you want to copy from directory() or adir() -- 
let's assume it's cFilename, then create a command line like

  "COPY /Y " + cFilename + " " + archivedir + "\" + ;
                "yyyymmdd-hhmmss-" + cFilename + ">nul"

and RUN it with your preferred execute function/command.

And if you want to delete the original after archiving, replace 
the COPY with MOVE -- this will save you having to do a manual 
deletion (this is safe as the original will not be deleted if the 
MOVE fails for whatever reason).

Hope that helps,
Pete

PS. On a design note, rather than have loads of files in a single 
archive directory, you might consider creating a "yyyymmdd" 
directory and creating the "hhmmss-stuff.dat" files in that dir.  
It depends on how many files/how often you're handling. This 
design might be appropriate if you are archiving hundreds of 
files each day.  Just a thought. 
-- 
   "We have not inherited the earth from our ancestors,
    we have borrowed it from our descendants."
0
pete11 (328)
5/23/2009 5:06:41 AM
Scott,

>I'm trying to write a program that will archive selected files to an
>archive directory.  The files in the archive directory will have a
>prefix in the format yyyymmdd-hhmmss-filename.ext.  So, if the file is
>called "somefile.dat", then the filename in the archive directory
>should be "20090522-164325-somefile.dat".  I'm using Clipper's COPY
>FILE command to do the copy.  I can't figure out how to get the prefix
>in front of the file name.  Creating the prefix string is no problem,
>but I can't figure out how to tack that onto the front of the
>filename.  If I could retrieve the name of the file into a character
>variable then my problem would be solved but I can't figure out how to
>do that.  I saw where I could get the name of a .dbf file but not of a
>.txt or other type of file.  Any ideas?

Provided that you are using Clipper 5.x and provided that you don't
have to do this on NT4, then you can use the LFN Library as suggested
by my friends. Use LF_Directory() or LF_FindFirst() and LF_FindNext()
to find the files and LF_Fcopy( <cOldName>, <cNewLongName> ) to copy
the files.

Regards,
Klas

-------
klas dot engwall at engwall dot com

http://www.engwall.com/clipper/

The LFN Library for Clipper
The LanMan Library for Clipper
The NFPAT1A Timeslice release patch for the Nanforum Toolkit
0
klas.engwall (791)
5/24/2009 12:22:13 AM
On Sat, 23 May 2009 05:06:41 +0000 (UTC), pete@nospam.demon.co.uk
wrote:

>In article  <ZNGRl.12923$y61.2726@news-server.bigpond.net.au>
>           stevejqNO@bigpondSPAM.net.au "Stephen Quinn" writes:
>
>> Scott
>> 
>> Clipper file functions don't handle long filenames very well (ie outside the 
>> 8.3 convention)
>> 
>> CYA
>> Steve 
>
>Indeed.  Clipper will need some "help".
>
>My first thought was Klas' LFN library though I'm not sure if 
>COPY FILE will handle that internally.  And you didn't say 
>whether you are using S87 or 5.x (and I've forgotten from your 
>earlier posts); this lib only available for 5.x unless someone 
>has ported it in the last few years.
>
>You are talking LFN so I assume you're running on a Win32 of some 
>flavour.  You could try using the system32 COPY command: get the 
>name of the file you want to copy from directory() or adir() -- 
>let's assume it's cFilename, then create a command line like
>
>  "COPY /Y " + cFilename + " " + archivedir + "\" + ;
>                "yyyymmdd-hhmmss-" + cFilename + ">nul"
>
>and RUN it with your preferred execute function/command.
>
>And if you want to delete the original after archiving, replace 
>the COPY with MOVE -- this will save you having to do a manual 
>deletion (this is safe as the original will not be deleted if the 
>MOVE fails for whatever reason).
>
>Hope that helps,
>Pete
>
>PS. On a design note, rather than have loads of files in a single 
>archive directory, you might consider creating a "yyyymmdd" 
>directory and creating the "hhmmss-stuff.dat" files in that dir.  
>It depends on how many files/how often you're handling. This 
>design might be appropriate if you are archiving hundreds of 
>files each day.  Just a thought. 

Typically, the OP didn't give enough information for the kind
responders to erm... respond.  <G>

As all of you have mentioned, the Clipper COPY FILE command isn't
going to work here, so I will use Pete's advice and use the COPY
command.  That appears to be simpler than Klas's LFN library and with
my limited expertise, simple is always the best route.  :)

And thanks all for the directory()/adir() tip.  One of my biggest
problems with Clipper is simply knowing what's available.  It looks
like adir() + system32 COPY will do the job nicely.  

Here's some additional info, just in case someone can spot something
stupid in my thought process:

- Running Clipper 5.3 under XP.

- The application is a POS application.

- The idea behind what I'm doing is to create a "safety net" by saving
a handful of critical application files whenever the cash register (XP
based PC running Clipper POS app) is closed.  There is already a
procedure in place to copy the same critical files to a daily
directory (MON, TUE, etc) when the register is closed, but sometimes
the user inadvertently closes the register multiple times and "bad"
copies would overwrite "good" copies.  I *could* try to prevent
multiple closings, but it's just easier (long story) to preserve the
files.  I've decided to save file copies in a single directory with a
date/timestamp each time the register is closed.  Then if the user
closes out twice, I have both the first and second copy and can get
the correct files restored if I need to.

-  The number of files is small... about two dozen files.  My plan is
to keep about six months worth of files in this directory by
periodically purging files > 30 days old.  

-  This technique mirrors a technique used at the main office's
server, where the data each register sends to the office is archived
in a single directory with a date/timestamp.  The users are
comfortable with this directory/filename structure on the main server,
so I'm simply mirroring that concept on the register itself.  It's
actually quite easy to scroll through the date/timestamped files in
this single directory and find what you're looking for.

Thanks again for the responses guys.  There's no warm bodies here that
I can bounce this Clipper stuff off of, so I really depend on your
responses when I get stuck.  Do me a favor and don't die or anything
for then next few years.  :P
0
none2847 (96)
5/24/2009 7:26:01 PM
Scott,

>As all of you have mentioned, the Clipper COPY FILE command isn't
>going to work here, so I will use Pete's advice and use the COPY
>command.  That appears to be simpler than Klas's LFN library and with
>my limited expertise, simple is always the best route.  :)

If I may say so, using the LFN Library is really simpler than shelling
out and running the COPY command in Windows. And it gives you feedback
so you can check that the correct number of bytes were copied.

Regards,
klas

-------
klas dot engwall at engwall dot com

http://www.engwall.com/clipper/

The LFN Library for Clipper
The LanMan Library for Clipper
The NFPAT1A Timeslice release patch for the Nanforum Toolkit
0
klas.engwall (791)
5/24/2009 9:32:06 PM
In article  <4a19ba60.170424787@news.ett.com.ua>
           klas.engwall@nospam.please "Klas Engwall" writes:

> Scott,
> 
> >As all of you have mentioned, the Clipper COPY FILE command isn't
> >going to work here, so I will use Pete's advice and use the COPY
> >command.  That appears to be simpler than Klas's LFN library and with
> >my limited expertise, simple is always the best route.  :)
> 
> If I may say so, using the LFN Library is really simpler than shelling
> out and running the COPY command in Windows. And it gives you feedback
> so you can check that the correct number of bytes were copied.

This is of course the "proper" way to do it, given that the OP is 
running the right version of Clipper and the right OS, but judging 
by Scott's comments I'm assuming that he would rather avoid the 
LF_Support()/LF_Fopen() and the read/write hassle.

I know you have copious amounts of free time <bg; private joke> 
but perhaps next time you decide to visit your LFN lib, perhaps a 
LF_Filecopy(fromFile, toFile) function might be included?  I've 
no doubt that Scott would have gone for that had it been available.
Given the existing LF_* support functions, I'd guess that this 
would be a pure Clipper function and return very useful error 
codes in case of failure...

Just my 2p.

Cheers,
Pete
-- 
   "We have not inherited the earth from our ancestors,
    we have borrowed it from our descendants."
0
pete11 (328)
5/25/2009 1:05:58 PM
Pete,

>This is of course the "proper" way to do it, given that the OP is 
>running the right version of Clipper and the right OS, but judging 
>by Scott's comments I'm assuming that he would rather avoid the 
>LF_Support()/LF_Fopen() and the read/write hassle.

And he can easily avoid that hassle!

>I know you have copious amounts of free time <bg; private joke> 
>but perhaps next time you decide to visit your LFN lib, perhaps a 
>LF_Filecopy(fromFile, toFile) function might be included?  I've 
>no doubt that Scott would have gone for that had it been available.

That wheel has already been invented, and it is called LF_Fcopy(). A
friend of mine called Pete helped me polish the assembly code that
does the actual copying. OK, so it was a long time ago <g>.

 Syntax

      LF_Fcopy( <cSrcFile>, <cDestFile> [,<nBuffSize>] ;
      [,<l7143Supp>]) -> nBytesCopied

 Arguments

     <cSrcFile> is the path and name of the file to be copied

     <cDestFile> is the path and name of the new file to be created

     <nBuffSize> is the desired read/write buffer size (optional) in
     kilobytes. Valid buffer sizes are 1, 2, 4, 8, 16 and 32. The
     default is 16 KB.

     <l7143Supp> is an optional flag which tells LF_Fcopy() whether
     DOS function 7143h is supported or not on the destination drive,
     .T. if supported and .F. if not supported. DOS function 7143h is
     used for transferring the file date/time/attributes from the
     source file to the destination file and must at least be
     supported on the destination drive (or more specifically at the
     destination path since the drive root of the destination path may
     not be accessible). See below for details! If <l7143Supp> is not
     passed, LF_Fcopy() will check the destination path using
     LF_7143Supp() and decide for itself.

 Returns

     <nBytesCopied>, which is the number of bytes that were copied
     from the source file to the destination file

     If the specified source file is not found or an error occurs,
     -1 will be returned.

Description

     [ bla bla bla    lots of detalis    bla bla bla ] <g>

>Given the existing LF_* support functions, I'd guess that this 
>would be a pure Clipper function and return very useful error 
>codes in case of failure...

As usual, LF_Ferror() knows the reason if an error occurs (if
<nBytesCopied> is -1)

The example code in the docs can be cut down to a minimum by using
LF_Directory() instead of the original LF_FindFirst() and
LF_FindNext(). 

>Cheers,
>Pete

Sk�l <g>,
Klas

-------
klas dot engwall at engwall dot com

http://www.engwall.com/clipper/

The LFN Library for Clipper
The LanMan Library for Clipper
The NFPAT1A Timeslice release patch for the Nanforum Toolkit
0
klas.engwall (791)
5/25/2009 11:31:18 PM
Hi Klas,

In article <4a1b23d2.909557@news.ett.com.ua> you wrote:

> Pete,
> 
> >This is of course the "proper" way to do it, given that the OP is 
> >running the right version of Clipper and the right OS, but judging 
> >by Scott's comments I'm assuming that he would rather avoid the 
> >LF_Support()/LF_Fopen() and the read/write hassle.
> 
> And he can easily avoid that hassle!
> 
> >I know you have copious amounts of free time <bg; private joke> 
> >but perhaps next time you decide to visit your LFN lib, perhaps a 
> >LF_Filecopy(fromFile, toFile) function might be included?  I've 
> >no doubt that Scott would have gone for that had it been available.
> 
> That wheel has already been invented, and it is called LF_Fcopy().

Well I'll be *******!  I couldn't find the copy of LFN lib that I 
know I have around here somewhere, so before posting went to your 
website to see if LF_Filecopy() existed.  Needless to say I missed 
completely LF_Fcopy()...  Still at least you had the opportunity 
to let Scott know just how easy it will be!

> A friend of mine called Pete helped me polish the assembly code that
> does the actual copying. OK, so it was a long time ago <g>.

<*embarrassed*>  Yes, it was indeed a long time ago and I had 
forgotten that this was to do with file copying!

[snip description]

So, Scott -- this is The Way To Go!

> Sk�l <g>,
> Klas

And to you too, Klas.  Look out for that Aspall Premier Cru...

Pete
-- 
   "We have not inherited the earth from our ancestors,
    we have borrowed it from our descendants."
0
pete11 (328)
5/26/2009 4:42:45 AM
On Tue, 26 May 2009 04:42:45 +0000 (UTC), pete@nospam.demon.co.uk
wrote:

>Hi Klas,
>
>In article <4a1b23d2.909557@news.ett.com.ua> you wrote:
>
>> Pete,
>> 
>> >This is of course the "proper" way to do it, given that the OP is 
>> >running the right version of Clipper and the right OS, but judging 
>> >by Scott's comments I'm assuming that he would rather avoid the 
>> >LF_Support()/LF_Fopen() and the read/write hassle.
>> 
>> And he can easily avoid that hassle!
>> 
>> >I know you have copious amounts of free time <bg; private joke> 
>> >but perhaps next time you decide to visit your LFN lib, perhaps a 
>> >LF_Filecopy(fromFile, toFile) function might be included?  I've 
>> >no doubt that Scott would have gone for that had it been available.
>> 
>> That wheel has already been invented, and it is called LF_Fcopy().
>
>Well I'll be *******!  I couldn't find the copy of LFN lib that I 
>know I have around here somewhere, so before posting went to your 
>website to see if LF_Filecopy() existed.  Needless to say I missed 
>completely LF_Fcopy()...  Still at least you had the opportunity 
>to let Scott know just how easy it will be!
>
>> A friend of mine called Pete helped me polish the assembly code that
>> does the actual copying. OK, so it was a long time ago <g>.
>
><*embarrassed*>  Yes, it was indeed a long time ago and I had 
>forgotten that this was to do with file copying!
>
>[snip description]
>
>So, Scott -- this is The Way To Go!
>
>> Sk�l <g>,
>> Klas
>
>And to you too, Klas.  Look out for that Aspall Premier Cru...
>
>Pete

Many thanks gentlemen.  I'll look into it.
ScottCoffey at Scott dash(-) Coffey dot net
0
none2847 (96)
5/26/2009 5:04:01 PM
Pete,

>> That wheel has already been invented, and it is called LF_Fcopy().
>
>Well I'll be *******!  I couldn't find the copy of LFN lib that I 
>know I have around here somewhere, so before posting went to your 
>website to see if LF_Filecopy() existed.  Needless to say I missed 
>completely LF_Fcopy()...  Still at least you had the opportunity 
>to let Scott know just how easy it will be!
>
>> A friend of mine called Pete helped me polish the assembly code that
>> does the actual copying. OK, so it was a long time ago <g>.
>
><*embarrassed*>  Yes, it was indeed a long time ago and I had 
>forgotten that this was to do with file copying!

The modest sometimes forget, after a while, the valuable help they
have provided. And then it is up to the rest of us to remind them of
it. So if my friend is listening I would like to say again  -  thanks
for the great support when I got stuck in the assembly labyrinth. I
couldn't have done it without him.

Klas

-------
klas dot engwall at engwall dot com

http://www.engwall.com/clipper/

The LFN Library for Clipper
The LanMan Library for Clipper
The NFPAT1A Timeslice release patch for the Nanforum Toolkit
0
klas.engwall (791)
5/27/2009 2:33:37 AM
On Mon, 25 May 2009 23:31:18 GMT, klas.engwall@nospam.please (Klas
Engwall) wrote:

>Pete,
>
>>This is of course the "proper" way to do it, given that the OP is 
>>running the right version of Clipper and the right OS, but judging 
>>by Scott's comments I'm assuming that he would rather avoid the 
>>LF_Support()/LF_Fopen() and the read/write hassle.
>
>And he can easily avoid that hassle!
>
>>I know you have copious amounts of free time <bg; private joke> 
>>but perhaps next time you decide to visit your LFN lib, perhaps a 
>>LF_Filecopy(fromFile, toFile) function might be included?  I've 
>>no doubt that Scott would have gone for that had it been available.
>
>That wheel has already been invented, and it is called LF_Fcopy(). A
>friend of mine called Pete helped me polish the assembly code that
>does the actual copying. OK, so it was a long time ago <g>.
>
> Syntax
>
>      LF_Fcopy( <cSrcFile>, <cDestFile> [,<nBuffSize>] ;
>      [,<l7143Supp>]) -> nBytesCopied
>
> Arguments
>
>     <cSrcFile> is the path and name of the file to be copied
>
>     <cDestFile> is the path and name of the new file to be created
>
>     <nBuffSize> is the desired read/write buffer size (optional) in
>     kilobytes. Valid buffer sizes are 1, 2, 4, 8, 16 and 32. The
>     default is 16 KB.
>
>     <l7143Supp> is an optional flag which tells LF_Fcopy() whether
>     DOS function 7143h is supported or not on the destination drive,
>     .T. if supported and .F. if not supported. DOS function 7143h is
>     used for transferring the file date/time/attributes from the
>     source file to the destination file and must at least be
>     supported on the destination drive (or more specifically at the
>     destination path since the drive root of the destination path may
>     not be accessible). See below for details! If <l7143Supp> is not
>     passed, LF_Fcopy() will check the destination path using
>     LF_7143Supp() and decide for itself.
>
> Returns
>
>     <nBytesCopied>, which is the number of bytes that were copied
>     from the source file to the destination file
>
>     If the specified source file is not found or an error occurs,
>     -1 will be returned.
>
>Description
>
>     [ bla bla bla    lots of detalis    bla bla bla ] <g>
>
>>Given the existing LF_* support functions, I'd guess that this 
>>would be a pure Clipper function and return very useful error 
>>codes in case of failure...
>
>As usual, LF_Ferror() knows the reason if an error occurs (if
><nBytesCopied> is -1)
>
>The example code in the docs can be cut down to a minimum by using
>LF_Directory() instead of the original LF_FindFirst() and
>LF_FindNext(). 
>
>>Cheers,
>>Pete
>
>Sk�l <g>,
>Klas
>
>-------
>klas dot engwall at engwall dot com
>
>http://www.engwall.com/clipper/
>
>The LFN Library for Clipper
>The LanMan Library for Clipper
>The NFPAT1A Timeslice release patch for the Nanforum Toolkit

Just wanted to let you know Klas that your LF-Fcopy function worked
brilliantly.  And yes, it's much easier than invoking the COPY
command!
ScottCoffey at Scott dash(-) Coffey dot net
0
none2847 (96)
5/27/2009 1:12:02 PM
On 22 May 2009 15:51:01 -0500, Scott Coffey <none@noemail.com.invalid>
wrote:

>
>I'm trying to write a program that will archive selected files to an
>archive directory.  The files in the archive directory will have a
>prefix in the format yyyymmdd-hhmmss-filename.ext.  So, if the file is
>called "somefile.dat", then the filename in the archive directory
>should be "20090522-164325-somefile.dat".  I'm using Clipper's COPY
>FILE command to do the copy.  I can't figure out how to get the prefix
>in front of the file name.  Creating the prefix string is no problem,
>but I can't figure out how to tack that onto the front of the
>filename.  If I could retrieve the name of the file into a character
>variable then my problem would be solved but I can't figure out how to
>do that.  I saw where I could get the name of a .dbf file but not of a
>.txt or other type of file.  Any ideas?

OK, I now have the code written to handle this task:

********************************************************************
*
*  Now create files in the Archive directory with date/timestamp.
*  Filename format is yyyymmdd-hhmmss-file.ext
*  Files to be archived are in file BKPFILES.DBF.
*  Add/delete filename for this file to start/stop archiving.   
*

cFrmdir := "C:\POS\DATA\"
cTodir := "C:\POS\DATA\ARCHIVE\"

ft_mkdir( "C:\POS\DATA\ARCHIVE" )  // Create the archive directory 

*
*  Create the prefix.  All files copied will have the same date/time *
(yyyymmdd-hhmmss)
*

cPrefix := dtos( date() ) + "-" + substr( time(), 1, 2 ) + substr(
time(), 4, 2 ) + substr( time(), 7, 2 ) + "-"

use C:\POS\DATA\BKPFILES new alias BKP
do while !eof()
   cFilename := rtrim( BKP->FILENAME )
   cCopyto := cPrefix + cFilename
   lf_fcopy( cFrmdir + CFilename, cTodir + cCopyto )
   skip
enddo
**************************************************************************

Now I need some code to purge the archive directory of any files > x
days old.  I'm using Klas's LF_Directory function to get a list of
files in the archive directory.  But I'm stuck because of my poor
knowledge of Clipper arrays.  I understand how to extract elements
from the two-dimensional array, but I don't know how to write the
looping construct because I don't know how many elements (filenames)
are going to be in the array. So, if I used:

for I = 1 to x

to traverse the array, how big should x be?  Is there a function that
returns the number of elements in an array?  Or maybe there's a
function that returns the number of files in a directory and I can use
that for x.  If not, and I make x big enough to handle a huge number
of files, what happens when I try to reference an element of the array
when there are no more elements?  

TIA
-- 
ScottCoffey at Scott dash(-) Coffey dot net
0
none2847 (96)
5/27/2009 6:57:01 PM
Is there a function that returns the number of elements in an array?

Yes, LEN().

a1 := {"a", "b", "c"}
? LEN(a1)  // Will be "3"

a2 := {{"a", "b", "c"}, {"d", "e"}}
? LEN(a2)     // Will be "2"
? LEN(a2[1])  // Will be "3"

HTH, Eugene

0
pm771.am (390)
5/27/2009 7:52:23 PM
On Wed, 27 May 2009 12:52:23 -0700 (PDT), "Eugene F."
<pm771.am@gmail.com> wrote:

>Is there a function that returns the number of elements in an array?
>
>Yes, LEN().
>
>a1 := {"a", "b", "c"}
>? LEN(a1)  // Will be "3"
>
>a2 := {{"a", "b", "c"}, {"d", "e"}}
>? LEN(a2)     // Will be "2"
>? LEN(a2[1])  // Will be "3"
>
>HTH, Eugene

Perfect.  Thanks Eugene!
-- 
ScottCoffey at Scott dash(-) Coffey dot net
0
none2847 (96)
5/27/2009 8:54:02 PM
Scott,

>Just wanted to let you know Klas that your LF-Fcopy function worked
>brilliantly.  And yes, it's much easier than invoking the COPY
>command!

Glad to hear that it works for you! Thanks for the report.

Klas

-------
klas dot engwall at engwall dot com

http://www.engwall.com/clipper/

The LFN Library for Clipper
The LanMan Library for Clipper
The NFPAT1A Timeslice release patch for the Nanforum Toolkit
0
klas.engwall (791)
5/27/2009 9:56:19 PM
Scott,

>OK, I now have the code written to handle this task:
>
>********************************************************************
>*
>*  Now create files in the Archive directory with date/timestamp.
>*  Filename format is yyyymmdd-hhmmss-file.ext
>*  Files to be archived are in file BKPFILES.DBF.
>*  Add/delete filename for this file to start/stop archiving.   
>*
>
>cFrmdir := "C:\POS\DATA\"
>cTodir := "C:\POS\DATA\ARCHIVE\"
>
>ft_mkdir( "C:\POS\DATA\ARCHIVE" )  // Create the archive directory 

You may want to check first if the directory already exists and only
attempt to create it if it does not:

lDirectoryExists := LF_IsFile( cTodir, .T. )

If <lDirectoryExists> is .F. then try to create the directory:

lSuccess := LF_MkDir( cTodir )  // I swapped out the NanForum function

If <lSuccess> is .F. then you need to check why if failed. LF_Ferror()
will help you with that.

>*  Create the prefix.  All files copied will have the same date/time *
>(yyyymmdd-hhmmss)
>*
>
>cPrefix := dtos( date() ) + "-" + substr( time(), 1, 2 ) + substr(
>time(), 4, 2 ) + substr( time(), 7, 2 ) + "-"

It is possible to make that line much shorter by using the strtran()
function:

cPrefix := dtos( date() ) + "-" + strtran( time(), ":" ) + "-"


>use C:\POS\DATA\BKPFILES new alias BKP
>do while !eof()
>   cFilename := rtrim( BKP->FILENAME )
>   cCopyto := cPrefix + cFilename
>   lf_fcopy( cFrmdir + CFilename, cTodir + cCopyto )

It is a good idea to check the result of LF_Fcopy(). First find the
size of the source file (see below). Then compare that with the number
of bytes copied as reported by LF_Fcopy():

nBytesCopied := LF_Fcopy( cFrmdir + cFilename, cTodir + cCopyto )

>   skip
>enddo

I suppose that C:\POS\DATA\BKPFILES holds the names of the files that
you want to copy. To find the size of the source file I would suggest
that you do something like this for each filename found in the dbf:

#include "LFNLIB.CH"    // Put this line at the top of the prg file

aDirectory := LF_Directory( cFrmdir + cFilename )
if empty( aDirectory )
   // Not found! Failure that requires some action
else
   nSize := aDirectory[ 1, LFN_SIZE ]  // One file only
endif
nBytesCopied := LF_Fcopy( cFrmdir + cFilename, cTodir + cCopyto )
if nBytesCopied < nSize
   // LF_Fcopy() failed, check with LF_Ferror() what went wrong
endif

>**************************************************************************
>
>Now I need some code to purge the archive directory of any files > x
>days old.  I'm using Klas's LF_Directory function to get a list of
>files in the archive directory.  But I'm stuck because of my poor
>knowledge of Clipper arrays.  I understand how to extract elements
>from the two-dimensional array, but I don't know how to write the
>looping construct because I don't know how many elements (filenames)
>are going to be in the array. So, if I used:
>
>for I = 1 to x
>
>to traverse the array, how big should x be?  Is there a function that
>returns the number of elements in an array? 

aDirectory := LF_Directory( cTodir + "*.dbf" )
for i := 1 to len( aDirectory )
   // Do something with the file found in aDirectory[ i ]
next

>Or maybe there's a
>function that returns the number of files in a directory and I can use
>that for x.  If not, and I make x big enough to handle a huge number
>of files, what happens when I try to reference an element of the array
>when there are no more elements?  

Solved above. But the word "huge" worries me a little. How large is
"huge"? There are two limits to the possible size of the array
returned by LF_Directory(). First there is the formal 4096 size limit
of arrays in general, which LF_Directory() takes care of (except that
the additional files will never be found). If you have more than 4096
files you will have to use LF_FindFirst() and LF_FindNext() instead
and loop through all the files in the archive directory (or at least
the ones matching your file name skeleton) to find the ones you want
to delete.

The other limit is the string memory capacity. Each string in the
aDirectory array consumes some memory, and I am not sure if there is
enough room for the total length of 4096 file names. I have never
tested that limit. Again, LF_FindFirst() / LF_FindNext() will come to
your rescue if "huge" means thousands of files. If you use that
approach, be sure to look into the FileFind handle, how to retrieve it
from LF_FindFirst() and how to close it after the last LF_FindNext().
If you don't close it you will get a memory leak.

Good luck <g>

Regards,
Klas

-------
klas dot engwall at engwall dot com

http://www.engwall.com/clipper/

The LFN Library for Clipper
The LanMan Library for Clipper
The NFPAT1A Timeslice release patch for the Nanforum Toolkit
0
klas.engwall (791)
5/27/2009 9:56:20 PM
On Wed, 27 May 2009 21:56:20 GMT, klas.engwall@nospam.please (Klas
Engwall) wrote:

>Scott,
>
>>OK, I now have the code written to handle this task:
>>
>>********************************************************************
>>*
>>*  Now create files in the Archive directory with date/timestamp.
>>*  Filename format is yyyymmdd-hhmmss-file.ext
>>*  Files to be archived are in file BKPFILES.DBF.
>>*  Add/delete filename for this file to start/stop archiving.   
>>*
>>
>>cFrmdir := "C:\POS\DATA\"
>>cTodir := "C:\POS\DATA\ARCHIVE\"
>>
>>ft_mkdir( "C:\POS\DATA\ARCHIVE" )  // Create the archive directory 
>
>You may want to check first if the directory already exists and only
>attempt to create it if it does not:
>
>lDirectoryExists := LF_IsFile( cTodir, .T. )
>
>If <lDirectoryExists> is .F. then try to create the directory:
>
>lSuccess := LF_MkDir( cTodir )  // I swapped out the NanForum function
>
>If <lSuccess> is .F. then you need to check why if failed. LF_Ferror()
>will help you with that.
>
>>*  Create the prefix.  All files copied will have the same date/time *
>>(yyyymmdd-hhmmss)
>>*
>>
>>cPrefix := dtos( date() ) + "-" + substr( time(), 1, 2 ) + substr(
>>time(), 4, 2 ) + substr( time(), 7, 2 ) + "-"
>
>It is possible to make that line much shorter by using the strtran()
>function:
>
>cPrefix := dtos( date() ) + "-" + strtran( time(), ":" ) + "-"
>
>
>>use C:\POS\DATA\BKPFILES new alias BKP
>>do while !eof()
>>   cFilename := rtrim( BKP->FILENAME )
>>   cCopyto := cPrefix + cFilename
>>   lf_fcopy( cFrmdir + CFilename, cTodir + cCopyto )
>
>It is a good idea to check the result of LF_Fcopy(). First find the
>size of the source file (see below). Then compare that with the number
>of bytes copied as reported by LF_Fcopy():
>
>nBytesCopied := LF_Fcopy( cFrmdir + cFilename, cTodir + cCopyto )
>
>>   skip
>>enddo
>
>I suppose that C:\POS\DATA\BKPFILES holds the names of the files that
>you want to copy. To find the size of the source file I would suggest
>that you do something like this for each filename found in the dbf:
>
>#include "LFNLIB.CH"    // Put this line at the top of the prg file
>
>aDirectory := LF_Directory( cFrmdir + cFilename )
>if empty( aDirectory )
>   // Not found! Failure that requires some action
>else
>   nSize := aDirectory[ 1, LFN_SIZE ]  // One file only
>endif
>nBytesCopied := LF_Fcopy( cFrmdir + cFilename, cTodir + cCopyto )
>if nBytesCopied < nSize
>   // LF_Fcopy() failed, check with LF_Ferror() what went wrong
>endif
>
>>**************************************************************************
>>
>>Now I need some code to purge the archive directory of any files > x
>>days old.  I'm using Klas's LF_Directory function to get a list of
>>files in the archive directory.  But I'm stuck because of my poor
>>knowledge of Clipper arrays.  I understand how to extract elements
>>from the two-dimensional array, but I don't know how to write the
>>looping construct because I don't know how many elements (filenames)
>>are going to be in the array. So, if I used:
>>
>>for I = 1 to x
>>
>>to traverse the array, how big should x be?  Is there a function that
>>returns the number of elements in an array? 
>
>aDirectory := LF_Directory( cTodir + "*.dbf" )
>for i := 1 to len( aDirectory )
>   // Do something with the file found in aDirectory[ i ]
>next
>
>>Or maybe there's a
>>function that returns the number of files in a directory and I can use
>>that for x.  If not, and I make x big enough to handle a huge number
>>of files, what happens when I try to reference an element of the array
>>when there are no more elements?  
>
>Solved above. But the word "huge" worries me a little. How large is
>"huge"? There are two limits to the possible size of the array
>returned by LF_Directory(). First there is the formal 4096 size limit
>of arrays in general, which LF_Directory() takes care of (except that
>the additional files will never be found). If you have more than 4096
>files you will have to use LF_FindFirst() and LF_FindNext() instead
>and loop through all the files in the archive directory (or at least
>the ones matching your file name skeleton) to find the ones you want
>to delete.
>
>The other limit is the string memory capacity. Each string in the
>aDirectory array consumes some memory, and I am not sure if there is
>enough room for the total length of 4096 file names. I have never
>tested that limit. Again, LF_FindFirst() / LF_FindNext() will come to
>your rescue if "huge" means thousands of files. If you use that
>approach, be sure to look into the FileFind handle, how to retrieve it
>from LF_FindFirst() and how to close it after the last LF_FindNext().
>If you don't close it you will get a memory leak.
>
>Good luck <g>
>
>Regards,
>Klas
>
>-------
>klas dot engwall at engwall dot com
>
>http://www.engwall.com/clipper/
>
>The LFN Library for Clipper
>The LanMan Library for Clipper
>The NFPAT1A Timeslice release patch for the Nanforum Toolkit

"Huge" was probably a poor choice of words... I was going for dramatic
effect.  :)

After talking to the user, they want to keep 30 days worth of history,
which would equate to no more than about 750 files, so I'm assuming
that I'm OK there.

And thanks for the additional critiques above.  More good stuff for my
bag of Clipper tricks!
-- 
ScottCoffey at Scott dash(-) Coffey dot net
0
none2847 (96)
5/29/2009 6:11:01 PM
Scott,

>"Huge" was probably a poor choice of words... I was going for dramatic
>effect.  :)

I suspected something like that <g>

>After talking to the user, they want to keep 30 days worth of history,
>which would equate to no more than about 750 files, so I'm assuming
>that I'm OK there.

Yes, in the sense that you are well within Clipper's array size limit.
But watch out for the string memory. Before relasing the modified
application to your customer you should run a test with, say, a
thousand files in LF_Directory() so you know that it will not run out
of memory when the client reaches 750. You will have to do this test
with your "live" application because you have probably used up some of
that memory already before starting the cleanup routine. I think you
should be OK, but better safe than sorry.

>And thanks for the additional critiques above.  More good stuff for my
>bag of Clipper tricks!

Glad to help with whatever I can provide
Klas

-------
klas dot engwall at engwall dot com

http://www.engwall.com/clipper/

The LFN Library for Clipper
The LanMan Library for Clipper
The NFPAT1A Timeslice release patch for the Nanforum Toolkit
0
klas.engwall (791)
5/31/2009 10:40:31 PM
Reply:

Similar Artilces:

File, Find References, Copy Files: Truncating Long File Names
Hello All- I just experienced this behavior this morning. It was repeatable. Has anyone else seen this? The file Name was cut off after 57 characters. XP Pro SP2 2006 SP0 Office XP 2003 Pro Best Regards, Devon T. Sowell www.3-ddesignsolutions.com How long was the path name in total? Total including the file extension (.SLDASM) = 174. The file Extension was retained, just the Name was chopped off. These are my customer's files. Best Regards, Devon T. Sowell www.3-ddesignsolutions.com "TOP" <kellnerp@cbd.net> wrote in message news:1128364278.638472.150320@f14g2000...

file.exe file generation from file.m file
How to generate application (*.exe) file from *.m file, which has lots of graphics. Program was written for image watermarking by using image processing toolbox. I want to send this program some where else but with out sowing the program codes. By this *.exe no need to use matlab6.5 platform. Also tell me How to generate *.p file from *.m file Which is hide the code to user but for run this program need matlab6.5 Please give me some idea about it. it is very urgent for me. I will be very great full to you "Biswajit Kar" <hibiswajitkar@rediffmail.com> wrote in message ne...

Copy Files with long file names
Hi, I am using CopyFile (Scripting.FileSystemObject) to copy file from one location to another. The naming convention followed makes the file names (+ the path) lenghty and the total characters can exceed 260 characters. I would appreciate if you can let me know if there is any solution to bypass max limit (Filename + Path) of 260 characters. The copying of file from one location to another happens on the click of a button in MS Access Forms. Thanks in Advance. Regards Bala Access Version : Access 2003 The files (can be any type of files like .xls, .doc, .pdf etc..) i...

file extention from file file location
Hi, I am new to perl (only working on this one problem) but I program in other languages. We have an upload script written in cgi. Can anyone tell me how to get the file extension from the variable $File1 (actual file location on uploader's computer) then find out if it is equal to "txt" Thanks in advance for not telling me to read the manual. Ron -- PLEASE NOTE: comp.infosystems.www.authoring.cgi is a SELF-MODERATED newsgroup. aa.net and boutell.com are NOT the originators of the articles and are NOT responsible for their content. HOW TO POST to co...

File::Copy::copy With File Handles
The documentation for File::Copy warns against using file handles as arguments: Note that passing in files as handles instead of names may lead to loss of information on some operating systems; it is recommended that you use file names whenever possible. Does this refer to handles created with the older FileHandle module (which is used in the module's synopsis), IO::Handle subclasses, or both? In either case what's the issue with handles that may lead to data loss? Quoth MaggotChild <hsomob1999@yahoo.com>: > The documentation for File::Copy warns agai...

Obtain file path and file name using file chooser
Hi All, I want to obtain both file "path" and the filenamed MyText.txt ....as in "C:\Documents and Settings\bH\Desktop\MyShowWithFrame\MyText.txt" I have tried to discover the options shown in How to Use File Choosers (The Java=E2=84=A2 Tutorials Creating a GUI with JFC-Swing Using Swing Components).htm I cannot understand what options should be shown as but this does not work. Program snip: JButton opnButton =3D new JButton("Open a Text File..."); buttonPanel.add(opnButton); opnButton.addActionListener(new ActionListener() { public void...

Copying files while changing name and variable in file
I need to copy a file and change the name from 1 to 2, and 3, and so on... while doing this 5000 times I also need to sequentially replace 2 variables within the file also sequentially....is there an easy way to do this? I'm completely new to dos so any help would be a great help. thanks in advance!! "Midnight" <jessica_brooks@csx.com> wrote in message news:1146681973.453560.213800@j33g2000cwa.googlegroups.com... > I need to copy a file and change the name from 1 to 2, and 3, > and so on... while doing this 5000 times I also need to sequentially > replace 2 va...

copy data from .xlsx/.xls file as new records to an EXISTING .dbf file (via programming in a clipper 5.3 .PRG file)
.xlsx/.xls data be saved as new records in an existing .dbf file (to be done by programming in a clipper 5.3 .prg file) i have this in an .xlsx/.xls file: Name Hours Date Assign OPE Comments XXT 4.50 20/12/2014 AUDIT Conveyance checked 1314 books P01 12.05 23/12/2014 DUED1 Lunch computed net worth XXT .10 23/12/2014 M&A merged stock... 90H 2.00 02/01/2015 AUDIT Xerox found discrepancies can the 4 (or more records) be read & saved as 4 ...

Iteration through File.file? misses entries for which File.file?(entry) == true
Hello everyone, I'm new to Ruby, so I'm most likely making an elementary mistake. However, searching Google didn't help me find my answer, and after mucking around with irb I still haven't figured it out. I wrote a method that was intended to take all of the files in a given directory and put them into an array. Here's the code I wrote: def getFiles(dir) pwdFiles = Array.new Dir.foreach(dir) do |entry| pwdFiles.push(entry) if File.file?(entry) == true end end This works fine when called on the working directory --- that is, getFile...

Bash: strip file path and file extension from a file name in a $string?
It appears that Bash supports stripping a match of $substring from $string from the front and from the back of $string through the following commands: ${string#substring} ${string%substring} Yet, it doesn't appear that it is possible to simultaneously strip a couple of substrings from the front and from the back of a string, which is a bit of a problem if a user intends to strip the path and file extension from a file listing. Nonetheless, this is certainly possible. So, is it possible to strip both the path and the file extension from a file? If so, can anyone prov...

File name from file description
Hi, I am new to this group. I had just one small question Is it possible to get the file name back from file descriptor. i.e. I have written a function to overload the libc write using LD_PRELOAD my_write(int fd, void *buf, size_t nbytes) In this function is it possible to find the filename from "fd". thanks amit On 28 Mar 2006 11:45:02 -0800, in comp.lang.c , "poddar" <poddar007@gmail.com> wrote: >Hi, > >I am new to this group. I had just one small question > >Is it possible to get the file name back from file descriptor. C doesn't have ...

file names, reading files
Hello, I have a basic question about reading files. I have several data files where the filenames are identical except for a short (3 character) prefix. I inherited this code and the person who developed it was making a duplicate of each file and then deleting the prefix on the copied file so the following statement could read a generic "filename": ifstream inFile("filename", ios::out); There are 20 files so I'd like to avoid this manual operation each time I run the program. I want to add a prefix to the string "filename" before reading the file so I d...

Copy files with a .vbs file
Hi Im a complete newbe at this and would like som help. Im sure this is very easy to do but i dont have any idea as where to start. I would like to have a .vbs file that i can click on to open e message box where I can specify a file. That file should then be copied 5 times and different text should be added infront of the original file name, like this: Org: 12324.txt Result: text1_1234.txt text2_1234.txt text3_1234.txt text4_1234.txt text5_1234.txt Anyone who can help me with this or point me in the right direction? Best regards Daniel -- ------------------------...

Copying a file to another file
Hi, I wrote the following C program to copy a file to another file. #include <stdio.h> #include <stdlib.h> static FILE *open_file ( char *file, char *mode ) { FILE *fp = fopen ( file, mode ); if ( fp == NULL ) { perror ( "Unable to open file" ); exit ( EXIT_FAILURE ); } return fp; } int main ( int argc, char *argv[] ) { /* int ch;*/ FILE *from; FILE *to; char *buffer; long lSize; if ( argc != 3 ) { fprintf ( stderr, "Usage: %s <readfile1> <writefile2>\n", argv[0] ); exit (1);/* E...

Web resources about - How to copy a file to a file with a prefixed file name - comp.lang.clipper

Infiniti cars to be prefixed with “Q” and “QX” starting in the 2014 model year
... at the North American International Auto Show. Stay tuned to Slashgear and we’ll keep you updated on the happenings. Infiniti cars to be prefixed ...

Resources last updated: 2/3/2016 11:10:36 AM