Import with `archive` overwrites previous files imported on the same day and same rules

[ricklupton]

When using the new source and archive directives in CSV rules (which I like -- thanks!) I have an issue where the archived file in data is overwritten.

This is because the filename is data/RULESFILEBASENAME.TODAYDATE.csv, so running it twice on the same day will overwrite a previous file.

Often I will download some previous months' transactions (in e.g. 2 separate CSV files, one per statement) and import them on the same day to catch up, but this means that only the second file is archived (the first is overwritten).

I'd suggest probably best is to not overwrite existing files but instead add a unique suffix like data/rules_name.2025-12-15.2.csv or similar? Or possibly a higher precision timestamp instead of just the date.

[simonmichael]

Thanks for the report and feedback @ricklupton. You're right; this was a conscious choice just to limit complexity.

There's some value in that I think, but I would consider a PR exploring this.

Is it important to separate your downloads (for one account on day) by statement ? Would it be unreasonable to give them distinct file names ?

[simonmichael]

PS I did have a notion that archive could have an optional argument controlling the path/filename of the archive file. But we should consider if it's actually needed.

[ricklupton]

Is it important to separate your downloads (for one account on day) by statement ? Would it be unreasonable to give them distinct file names ?

With this bank, I don’t have a choice to download transactions over a longer period — they are only available with one file per statement period. So if I’m catching up with importing transactions from more than one statement, I’ll always be importing more than one file per account per day.

I’m not sure what you mean by distinct filenames — as far as I can see the name of the CSV file is ignored when choosing the archived file name?

[simonmichael]

I see. And you're right, thinking about it more the archive file is named after the rules file, so I guess I meant a separate rules file per month. Sounds like a hassle.

I'd rather not have both .DATE and .N suffixes. So adding a timestamp sounds like a reasonable workaround. Though it won't be obvious which period is in each file.

The timestamp would probably need to include seconds, and decimals too if we consider that somebody out there will be scripting their downloads. Those sounds a bit unpleasant for people who don't need them, which suggests that configurable archive file names might be justified.

[simonmichael]

An alternative is to do your own CSV file archiving first, naming them whatever you like, and then importing the data from there.