archiefmap en dubbele bestandsnamen

Ik heb een archiefmap aangemaakt zodat het mutatiebestand in dat archief wordt gezet nadat ik het heb ingelezen, dan houd ik mijn downloaddirectory schoon. Het werkt niet. Ik denk dat het komt omdat het mutatiebestand steeds dezelfde naam heeft. Er zouden dan bestanden met dezelfde naam in dat archief worden weggeschreven.
Hoe moet ik hier mee omgaan?

PS Ik gebruik Firefox, en mijn bank is Triodos. Bij het ophalen worden de mutatiebstanden steeds in dezelfde downloaddirectory gezet. (Als daar dubbele namen ontstaan, voegt Firefox er een volgnummer aan toe, maar omdat die downloaddirectory nu schoon is, krijg ik steeds dezelfde filenaam van de bank))

Op dit moment zal BankTrans het bestand inderdaad niet verplaatsen na succesvol inlezen.

De oplossing van FireFox klinkt in dit geval inderdaad logisch en die zal ik in één van de volgende versies van BankTrans inbouwen. Zodra deze aanpassing beschikbaar is zal ik het laten weten.

Vanaf versie 1.79 zal BankTrans ook een volgnummer toevoegen aan de bestandsnaam indien deze al bestaat in de archiefdirectory. Deze nieuwe versie is vanaf nu beschikbaar.

Tonnie,

1) De RABO import-bestanden heten standaard 'mut.txt'.
2) Om ze overzichtelijk uit elkaar te kunnen houden rename ik ze altijd door er de banknaam en een datum aan toe te voegen. Dus bijv. 'mut RABO_20121109.txt'.
3) In 1.79 wordt nu, bij gelijke importbestandsnamen in het archief een volgnummer toegevoegd.

Deze 3 punten gecombineerd leidde mij naar het volgende idee. De mogelijkheid
bieden om als volgnummer een datum_tijd-nummer (net zoals in de backup-files) te gebruiken. Via Instellingen zou eventueel de keuze uit verschillende nummersoorten en/of stramiens ingesteld kunnen worden.

Alleen een datum is niet voldoende, stel dat je twee keer op een dag een mutatiefile binnenhaalt, dan zou je toch weer een dubbele naam kunnen krijgen.
Is op te lossen door toch een volgnummer toe te passen, of een timestamp.

Timestamp lijkt me hier de beste optie.
Hiermee ben je altijd uniek en voorkom je dubbele namen.
Volgnummer zou ook wel kunnen, maar ga je dan per bank een volgnummer hanteren, of per import etc....
Volgens mij is timestamp dan eenvoudiger...

Zappy,

... De mogelijkheid
bieden om als volgnummer een datum_tijd-nummer (net zoals in de backup-files) te gebruiken. ...

Mijn idee/voorstel was dus date- plus timestamp!

Jan,

... Via Instellingen zou eventueel de keuze uit verschillende nummersoorten en/of stramiens ingesteld kunnen worden. ...

Het onderscheid per bank o.i.d. zou gemaakt kunnen worden door in Instellingen een stramien te kunnen definiëren, zoals bijv. "mut-RABO_<date>-<time>". Dit geeft dan "mut-RABO_20121111-0845".

OK, ik begrijp je punt. Ik vraag me wel af wat de toegevoegde waarde is.
Ik heb nu een paar bestanden ingelezen met de nieuwste versie van BankTrans en hij geeft keurig een volgnummer aan dubbele bestandsnamen in de archiefmap.
Voor mij is dat voldoende. Als ik die mutatiefiles ooit nodig zal hebben, kan ik hiermee uit de voeten.
Wat mij betreft (weer) een pluim voor Tonnie!!

Zappy,

Ik vraag me wel af wat de toegevoegde waarde is.

Meer dan een enkel nummer, is een datum/tijd-'nummer' bij het terugzoeken een duidelijker 'identificeerder'. Nogmaals, dat is mijn mening/idee, mede ingegeven door het feit dat ik om die reden mijn importbestandsnamen reeds van een datum voorzie.

Wat mij betreft (weer) een pluim voor Tonnie!!

Wat mij betreft een dikke +1.

Hallo,

Naar aanleiding van alle bovenstaande opmerkingen zou ik het volgende willen voorstellen:

1. Ik verplaats de instelling voor de archiefmap van het instellingenscherm naar de instellingen voor de rekeningen. Zodoende kunnen er per rekening verschillende mappen worden gebruikt.
2. Bij de instellingen voor de rekeningen komt een nieuw vinkje waarmee je per rekening kan aangeven of de datum/tijd aan een bestand moet worden toegevoegd bij het archiveren.

Voor zover ik het kan overzien zijn hiermee alle gewenste mogelijkheden dan aanwezig. Ik hoor graag of jullie het hiermee eens zijn.

Mvg., Tonnie