# Naming of repeat CSVs in Briefcase export in v1.12.1

**URL:** <https://forum.getodk.org/t/naming-of-repeat-csvs-in-briefcase-export-in-v1-12-1/15495>\
**Category:** Development\
**Tags:** odk-meta, odk-briefcase\
**Created:** [October 1, 2018, 5:07pm UTC](https://forum.getodk.org/t/naming-of-repeat-csvs-in-briefcase-export-in-v1-12-1/15495 "2018-10-01T17:07:48Z")\
**Posts on this page:** 1\
**Showing post:** 8

<div class="post-metadata">

**Author:** ![LN](https://getodk.b-cdn.net/user_avatar/forum.getodk.org/ln/32/1605_2.png) [@LN](https://forum.getodk.org/u/LN)\
**Post date:** [October 3, 2018, 6:46pm UTC](https://forum.getodk.org/t/naming-of-repeat-csvs-in-briefcase-export-in-v1-12-1/15495/8 "2018-10-03T18:46:11Z")

</div>

> [@ODK Meta - Repeat Groups not merging](https://forum.getodk.org/t/odk-meta-repeat-groups-not-merging/15308/24):
>
> Apparently there is a [Windows limit](https://docs.microsoft.com/en-us/windows/desktop/fileio/naming-a-file#maximum-path-length-limitation) such that file paths (not just file basenames) cannot exceed 260 characters.

Aha, yes, I had a fuzzy memory of such a thing. Unfortunately, I think that means using the fully qualified name isn't a good option. 260 goes really fast if a user organizes their files in subfolders. 😭

I can't help but wonder whether `odkmeta` and other downstream tools could use the contents of each CSV to determine what it represents rather than parsing the filename? It seems that might be less brittle.

Either way, at this point I'm leaning towards merging [https://github.com/opendatakit/briefcase/pull/659](https://github.com/opendatakit/briefcase/pull/659) for now to revert the FQN behavior introduced in 1.12.1 (sorry I got that wrong above, @ggalmazor) and continuing the conversation.

---

_[View the full topic](https://forum.getodk.org/t/naming-of-repeat-csvs-in-briefcase-export-in-v1-12-1/15495)._