I have a script with a number of cp commands that are structured as:
cp -Rcvn /fromdir /todir. This script has been in service for 2 years and
copies data files from QNX to a USB 2 drive formatted as FAT32 (a mix of t11
& t12 drives) - Fatfsys and Fsys.umass are also used in the process. Today,
a review of the script’s log file shows that all files are copied every time
the script is run even though previously copied versions of the files
haven’t changed.
As a test the script was run 3 times in succession with 11 files total and
one new file yet to be copied. First run all files were copied. Second
re-run, 4 files were copied. Third re-run 0 files were copied.
It appears the ‘n’ parameter is being ignored and I’m not understanding why
this is happening! I use this form of the command daily and it works with
QNX to QNX copies.
Can anyone shed some light?
Thanks,
Gord
“Gord Sipko” <mountkidd_AT_shaw_DOT_ca@nospam.com> wrote in message
news:femol2$sa$1@inn.qnx.com…
I have a script with a number of cp commands that are structured as:
cp -Rcvn /fromdir /todir. This script has been in service for 2 years and
copies data files from QNX to a USB 2 drive formatted as FAT32 (a mix of
t11 & t12 drives) - Fatfsys and Fsys.umass are also used in the process.
Today, a review of the script’s log file shows that all files are copied
every time the script is run even though previously copied versions of the
files haven’t changed.
As a test the script was run 3 times in succession with 11 files total and
one new file yet to be copied. First run all files were copied. Second
re-run, 4 files were copied. Third re-run 0 files were copied.
It appears the ‘n’ parameter is being ignored and I’m not understanding
why this is happening! I use this form of the command daily and it works
with QNX to QNX copies.
I’m guessing Fatfsys is having problem with date? Try Fsys.dos or Dosfsys.
Don’t know which one is the more recent 
Can anyone shed some light?
Thanks,
Gord
Don’t FAT timestamps have a two-second resolution? If the timestamp on
the original file had an odd number of seconds, FAT will round it down,
and the copy will look one second older.
Mario Charest wrote:
“Gord Sipko” <> mountkidd_AT_shaw_DOT_ca@nospam.com> > wrote in message
news:femol2$sa$> 1@inn.qnx.com> …
I have a script with a number of cp commands that are structured as:
cp -Rcvn /fromdir /todir. This script has been in service for 2 years and
copies data files from QNX to a USB 2 drive formatted as FAT32 (a mix of
t11 & t12 drives) - Fatfsys and Fsys.umass are also used in the process.
Today, a review of the script’s log file shows that all files are copied
every time the script is run even though previously copied versions of the
files haven’t changed.
As a test the script was run 3 times in succession with 11 files total and
one new file yet to be copied. First run all files were copied. Second
re-run, 4 files were copied. Third re-run 0 files were copied.
It appears the ‘n’ parameter is being ignored and I’m not understanding
why this is happening! I use this form of the command daily and it works
with QNX to QNX copies.
I’m guessing Fatfsys is having problem with date? Try Fsys.dos or Dosfsys.
Don’t know which one is the more recent >
Can anyone shed some light?
Thanks,
Gord
\
–
Wojtek Lerch
QNX Software Systems
Wojtek Lerch wrote:
Don’t FAT timestamps have a two-second resolution? If the timestamp on
the original file had an odd number of seconds, FAT will round it down,
and the copy will look one second older.
Sounds pretty clever! Yes, mtime is 2-sec granularity. Check times
with “ls -l”. If this was the case, QNX->QNX,FAT->FAT,FAT->QNX would
work, just not QNX->FAT.
Sometimes “cp -t” is useful with FAT, and it might work here if you
don’t mind your copy having the current copy time versus the actual
modification time (it should always look “new” this way)?
Mario Charest wrote:
I have a script with a number of cp commands that are structured as:
cp -Rcvn /fromdir /todir. This script has been in service for 2
years and copies data files from QNX to a USB 2 drive formatted as
FAT32 (a mix of t11 & t12 drives) - Fatfsys and Fsys.umass are also
used in the process. Today, a review of the script’s log file shows
I’m guessing Fatfsys is having problem with date? Try Fsys.dos or
Dosfsys. Don’t know which one is the more recent >
Don’t do that, neither of those support FAT32, you want Fatfsys!
If the two second issue doesn’t explain this, consider that Fatfsys
only has one time/date, whereas the QNX (Posix) file system has at
least 3. It could be that the FatFsys mapping of these time stamps
is the problem.
“John Garvey” <jgarvey@qnx.com> wrote in message
news:feo51b$ve$1@inn.qnx.com…
Wojtek Lerch wrote:
Don’t FAT timestamps have a two-second resolution? If the timestamp on
the original file had an odd number of seconds, FAT will round it down,
and the copy will look one second older.
Sounds pretty clever! Yes, mtime is 2-sec granularity. Check times
with “ls -l”. If this was the case, QNX->QNX,FAT->FAT,FAT->QNX would
work, just not QNX->FAT.
Sometimes “cp -t” is useful with FAT, and it might work here if you
don’t mind your copy having the current copy time versus the actual
modification time (it should always look “new” this way)?
This might be a good solution here because the copy happens immediately
after the file is created & closed. I will do some testing and see if this
clears up the problem. Thanks for the great suggestion!
Mario Charest wrote:
I have a script with a number of cp commands that are structured as:
cp -Rcvn /fromdir /todir. This script has been in service for 2 years
and copies data files from QNX to a USB 2 drive formatted as FAT32 (a
mix of t11 & t12 drives) - Fatfsys and Fsys.umass are also used in the
process. Today, a review of the script’s log file shows
I’m guessing Fatfsys is having problem with date? Try Fsys.dos or
Dosfsys. Don’t know which one is the more recent >
Don’t do that, neither of those support FAT32, you want Fatfsys!
Fatfsys is more recent than Dosfsys and has support for FAT32!
“Gord Sipko” <mountkidd_AT_shaw_DOT_ca@nospam.com> wrote in message
news:fepep2$qv0$1@inn.qnx.com…
“John Garvey” <> jgarvey@qnx.com> > wrote in message
news:feo51b$ve$> 1@inn.qnx.com> …
Wojtek Lerch wrote:
Don’t FAT timestamps have a two-second resolution? If the timestamp on
the original file had an odd number of seconds, FAT will round it down,
and the copy will look one second older.
Sounds pretty clever! Yes, mtime is 2-sec granularity. Check times
with “ls -l”. If this was the case, QNX->QNX,FAT->FAT,FAT->QNX would
work, just not QNX->FAT.
Sometimes “cp -t” is useful with FAT, and it might work here if you
don’t mind your copy having the current copy time versus the actual
modification time (it should always look “new” this way)?
This might be a good solution here because the copy happens immediately
after the file is created & closed. I will do some testing and see if
this clears up the problem. Thanks for the great suggestion!
I tried and tested using the -t option and it seems to solve the problem for
all but one set of files. I can live with this but will look into the
closing side for this file group and see if it too can be resolved.
Thanks again John!
Mario Charest wrote:
I have a script with a number of cp commands that are structured as:
cp -Rcvn /fromdir /todir. This script has been in service for 2 years
and copies data files from QNX to a USB 2 drive formatted as FAT32 (a
mix of t11 & t12 drives) - Fatfsys and Fsys.umass are also used in the
process. Today, a review of the script’s log file shows
I’m guessing Fatfsys is having problem with date? Try Fsys.dos or
Dosfsys. Don’t know which one is the more recent >
Don’t do that, neither of those support FAT32, you want Fatfsys!
Fatfsys is more recent than Dosfsys and has support for FAT32!