P
Phred
G'day mates,
I have a file renaming problem for which I hope someone may be able to
point me to a practical solution, please. Either a cheap (or free
existing application, or guidance on how to create a suitable batch
routine (Windows ME and/or Windows 2000/XP) would be acceptable
solutions, if practical.
The files are data files captured every 3 hours (but usually only
about six files/day on average after allowing for corrupted and/or
"nonexistent" files) and they are transferred to a PC approximately
every 3 days (or less) to ensure some are not lost. (While the source
system can actually store up to 26 files before the FIFO rule is
applied, that's still only about 3 days of a really good run.)
The naming convention on the source system is numerically newest to
oldest with two digits (i.e. NAME01.EXT to NAME26.EXT where 01 is the
current file and 26 the oldest). The oldest file (26) is dropped at
the next data input when the file names in the remainder of the set
are incremented and a new 01 is added.
When transferred to PC, the files are stored in a structure that looks
like:
C:\level1\level2\level3\DATASET\yymmddhh\NAME##.EXT
where yymmddhh is simply code for year/month/day/hour when downloaded
and ## is 01 to 26 (max) as explained above. [In fact, there are
several DATASETs involved, with currently between 100 and 200 of those
yymmddhh subdirs in each. While that shouldn't affect the logic of
any proposed solution, it does explain why I'm keen to have the
process automated as far as possible!]
With me so far?
Okay, what I want to end up with is a numerical sequence of files
within ~\DATASET\ which runs from oldest to newest (i.e. the oldest
file becomes 0001 and the newest is NNNN, where 0001 <NNNN <=9999 ) so
the naming scheme is essentially open-ended. [Note that "oldest" and
"newest" are defined by the file names and *not* necessarily by file
creation date as stored on the HDD.]
In fact, I would like to be able to define subsets of these sequences,
based on a span of dates in that yymmddhh format that conforms to the
subdirectory naming scheme. Whether each of the subsets starts again
from 1=oldest, or simply continues the sequence from the previous
subset, is a moot point as there are potential advantages in both
approaches. But if the latter is adopted, it probably means using a
base starting at 00001 if it's to be used in the reasonably long term
-- or even 000001, remembering the millennium. ;-)
So let's assume the latter (starting from 1 then just becomes a
particular case). To simplify things a bit, it would be acceptable to
assume the renaming logic starts from a particular DATASET as the
"current directory" (though changing to that would probably be only a
trivial complication anyway).
I would then like to specify:
1. A range of subdirectories to operate on at the next level in the
form yymmddhh (e.g. 04022106 to 04040712)
2. A "root" alphanumeric file name for the series (probably just 2
characters in order to keep to a standard 8.3 file name) and
3. A sequence starting number in the form NNNNNN, which could be
explicitly stated or, if not, then defaults to a previously stored
number based on the previous run IN THAT DATASET so the sequence
continues incrementing logically from that previous point.
It would be necessary for the programmed solution to sort the yymmddhh
directories to be processed in ascending order, and then sort and
process the files within each in descending order of the original
names but ascending order of the newly assigned names; with a "carry"
of the sequence into the next yymmddhh directory in the set.
Note that the renamed files are to be transferred to a common
location (preferably specified as part of the process; but a built-in
"temporary" location would be acceptable if necessary). They are NOT
to be renamed and left in situ in that myriad of yymmddhh subdirs.
It would also be preferable, though not essential, to COPY/RENAME the
files to the new location as part of the renaming, rather than doing a
MOVE/RENAME. [Not essential because the alternative option would be
to create a duplicate set to work on prior to doing the job, rather
than making the duplicate set as part of the renaming procedure.]
Thanks very much for your interest in at least reading this far!
Cheers, Phred.
I have a file renaming problem for which I hope someone may be able to
point me to a practical solution, please. Either a cheap (or free
existing application, or guidance on how to create a suitable batch
routine (Windows ME and/or Windows 2000/XP) would be acceptable
solutions, if practical.
The files are data files captured every 3 hours (but usually only
about six files/day on average after allowing for corrupted and/or
"nonexistent" files) and they are transferred to a PC approximately
every 3 days (or less) to ensure some are not lost. (While the source
system can actually store up to 26 files before the FIFO rule is
applied, that's still only about 3 days of a really good run.)
The naming convention on the source system is numerically newest to
oldest with two digits (i.e. NAME01.EXT to NAME26.EXT where 01 is the
current file and 26 the oldest). The oldest file (26) is dropped at
the next data input when the file names in the remainder of the set
are incremented and a new 01 is added.
When transferred to PC, the files are stored in a structure that looks
like:
C:\level1\level2\level3\DATASET\yymmddhh\NAME##.EXT
where yymmddhh is simply code for year/month/day/hour when downloaded
and ## is 01 to 26 (max) as explained above. [In fact, there are
several DATASETs involved, with currently between 100 and 200 of those
yymmddhh subdirs in each. While that shouldn't affect the logic of
any proposed solution, it does explain why I'm keen to have the
process automated as far as possible!]
With me so far?
Okay, what I want to end up with is a numerical sequence of files
within ~\DATASET\ which runs from oldest to newest (i.e. the oldest
file becomes 0001 and the newest is NNNN, where 0001 <NNNN <=9999 ) so
the naming scheme is essentially open-ended. [Note that "oldest" and
"newest" are defined by the file names and *not* necessarily by file
creation date as stored on the HDD.]
In fact, I would like to be able to define subsets of these sequences,
based on a span of dates in that yymmddhh format that conforms to the
subdirectory naming scheme. Whether each of the subsets starts again
from 1=oldest, or simply continues the sequence from the previous
subset, is a moot point as there are potential advantages in both
approaches. But if the latter is adopted, it probably means using a
base starting at 00001 if it's to be used in the reasonably long term
-- or even 000001, remembering the millennium. ;-)
So let's assume the latter (starting from 1 then just becomes a
particular case). To simplify things a bit, it would be acceptable to
assume the renaming logic starts from a particular DATASET as the
"current directory" (though changing to that would probably be only a
trivial complication anyway).
I would then like to specify:
1. A range of subdirectories to operate on at the next level in the
form yymmddhh (e.g. 04022106 to 04040712)
2. A "root" alphanumeric file name for the series (probably just 2
characters in order to keep to a standard 8.3 file name) and
3. A sequence starting number in the form NNNNNN, which could be
explicitly stated or, if not, then defaults to a previously stored
number based on the previous run IN THAT DATASET so the sequence
continues incrementing logically from that previous point.
It would be necessary for the programmed solution to sort the yymmddhh
directories to be processed in ascending order, and then sort and
process the files within each in descending order of the original
names but ascending order of the newly assigned names; with a "carry"
of the sequence into the next yymmddhh directory in the set.
Note that the renamed files are to be transferred to a common
location (preferably specified as part of the process; but a built-in
"temporary" location would be acceptable if necessary). They are NOT
to be renamed and left in situ in that myriad of yymmddhh subdirs.
It would also be preferable, though not essential, to COPY/RENAME the
files to the new location as part of the renaming, rather than doing a
MOVE/RENAME. [Not essential because the alternative option would be
to create a duplicate set to work on prior to doing the job, rather
than making the duplicate set as part of the renaming procedure.]
Thanks very much for your interest in at least reading this far!
Cheers, Phred.