Page 1 of 1

wrong date

PostPosted: Tue Jul 02, 2013 8:40 pm
by intelit
Hi there,

i'm using the following lines to rename some files:

brc64.exe /Pattern:ISP004.csv /ReplaceCI:ISP004:DE1537_ /Appenddate:C:S:::10:"%y%m%d_00401" /execute

But today (130702) I recevied a message that the file could not be renamed to "DE1537_130701_00401.csv" which is true because a so named file was created yesterday.

The Problem was solved for one day after a reboot of the System (Windows 7) but now it's back again.
Things worked well for at least 2 weeks at last.

Any suggestions?

Kind regards
intelit

BRC was denied permission

PostPosted: Wed Aug 14, 2013 1:53 am
by truth
My guess is that we're only seeing part of your commandline?
That commandline works fine by itself, but not along with a /regexp removing too many previous chars
If any of your files had the same CreateDate, this could definitely be an issue (going by your posted FinalName)
You'd either have to preserve more chars, or add %M%S or /nodupe to prevent duplicate filenames

The main point is that /append___ matches everything spec'd in /pattern (not by-date, or anything-else)
If a filename meets /pattern's requirements, append will try to rename it (but can fail to permission issues)
The only exception is that read-only/hidden/system-files are auto-filtered before /pattern starts filtering
Not your issue, since BRC never tries to rename them - thus no error

Re: wrong date

PostPosted: Fri Sep 27, 2013 1:49 pm
by intelit
Problem still exists.
Now also I did a complete reboot of the machine the date string is always set to "130819" instead of "130927" which would be right.

There is a problem with the date data in the brc64.exe!!!

If anybody has an solution please let me know...

intelit

Wrong CreateDate = Wrong Appended CreateDate

PostPosted: Fri Sep 27, 2013 6:16 pm
by truth
Since you're using /AppendDate:C
The 'date string' or 'date data' is the CreateDate of the file being renamed
Never heard of it getting locked before - I'd confirm the file's CreateDate

IF I had your suspicion, I'd test the file without /execute to preview NewName
That would confirm internal buffers to be holding the correct data for %y%m%d

Thus far, it still sounds like your issue is:
Wrong(same)CreateDate -> WrongAppendedCreateDate -> DuplicateFilename = RenamePermissionDenied