Long filenames can lead to presumed corrupt /workspace folder (includes solution)

[cjclip]

maybe

[Lizard-of-Oz]

@Sandroid

For future reference:

this issue was caused by filenames that are too long and were not within the limitation of the FAT32 Filesystem.

Maybe I missed it, but the actual limit is never mentioned here.

Is it 256 characters for the full path, as mentioned here, or is it something else?

Edit: this post explains that the limit would be 256 characters for the full path.

Also I’m curious: if a file has a filename that would exceed the length of the limits of the file system, how is it possible that file is stored there in the first place? I would expect that either the copy operation is unsuccessful, or the file name is truncated. Either case would not lead to a file name that exceeds 256 characters, because that is the limitation of the file system.

@cjclip

It was an issue with overly long file names.

Did you just edit the filenames on the SD Card to make them shorter, or how exactly did you fix this?

[cjclip]

I created long names for patches on the computer, such as Pad_Iridium_Atmo_Ambient_Stars_keyC, and this caused issues on the Synth. Then I renamed the patch to a shorter name, P_Stars_C, on the computer, and everything worked fine, even though the file name for the patch itself was quite long, like Pad_Iridium_Atmo_Ambient_Stars_keyC.wav.

However, this didn’t affect the operation; the problem was somehow with the name of the patch itself.

[Lizard-of-Oz]

Ok, then that I would assume that has nothing to do with 256 character the limit imposed by the filesystem, because the full path of

/Samples/GRAINS/Pad_Iridium_Atmo_Ambient_Stars_keyC.wav

has a length of only 56 characters.

Well, and also because you can’t rename a file to a name that exceeds that limit, or copy one over to the card in the first place.

Just to for comparison: this filename has 257 characters and would exceed the filesystem’s limit by a single character:

/Samples/GRAINS/ThisIsAFileNameThatExceedsTheLimitsOfTheFAT32FIleSystemAndAsYouCanSeeThisIsOneHellOfAFilenameThereAreSeveralNovelsShorterThanThisAreWeDoneYeyNoNotQuiteThereIsStillSomeWayToGoIKnowItsExhaustingButBearWithMeIcanFeelItsCloseJustOneMoreStep.wav

To sum up what we know:

• shortening the filename will solve the problem
• it may be by design, but not by design of the filesystem
• the actual maximum length of a filename is not 256, but a lot lower, and we don’t know the actual number just yet

[D-Jameses]

I’m not sure if this might help to clarify anything, but I got a little help with copilot and just asked the question regarding the actual limitations of the the FAT32 filesystem and got this:

The 255-character limitation in FAT32 applies to the file name itself, not the entire file path. However, there are additional limitations regarding the total length of the file path:

1. File Name: Each individual file name can be up to 255 characters long.
2. Total Path Length: The total length of the file path, which includes the directory names and the file name, can be up to 260 characters.

Nested directories are subject to these limitations as well. If the combined length of the directory path and the file name exceeds 260 characters, it will not be supported by the FAT32 file system.

Here’s an example to illustrate this:

• File Name: examplefilename.txt (17 characters)
• Directory Path: C:\Folder1\SubFolder2\SubFolder3\SubFolder4\ (43 characters)

The total path would be: C:\Folder1\SubFolder2\SubFolder3\SubFolder4\examplefilename.txt (60 characters).

As long as this combined length stays within the 260-character limit, you’re good to go. If you exceed this limit, you would need to shorten the directory names or the file name.

[Lizard-of-Oz]

Ah, so it’s even more than the 256 characters, good to know. The actual limits are still way shorter.

I made some tests with long names for samples by simply duplicating and renaming samples on the SD-Card. Samples with a length (including extension, but not the full path) of 80 characters or more simply don’t show up in the sample selector. Also files with emoji in the name are ignored, but these ignored files don’t caused any problems on reboot. I also tested characters like “ä”, these work but are displayed as a white square.

For presets, the limit appears to be 87 characters, again, presets a name of 87 characters or more are ignored by the preset browser. When I tried saving a preset with a name long name within the synth, I was able to enter 81 characters, and the file saved to disk, but the preset does not show up in the preset browser, because 81 characters + “.patch” makes 87. However, the name of the preset is still visible on top if the preset browser, and the file does exist on the SD-Card.

In the scene itself, two odd things happen: When I try saving that to a scene, two things happen:

• when I switch between the 3 synth slots, slots 1, 2 and3 each display parts of the long preset name on top the screen (where the preset name is supposed to be)
• when I save that scene, it is actually not written to disk, because when I load it a gain, the engine in slot 1 that I changed to GRAIN from ACD before saving the preset reverts to ACD

A preset with filenames that is a bit shorter shorter does save to disk properly, but still breaks the scene. Did not test enough to figure out the actual limits/

So there is something going on, however I could not get the Synth to crash on reboot

I also saved a scene with a really long name from within Synth, and noticed that name was truncated to 31 characters on disk, so there is some precautions in place there.

BTW, deleting samples that were used in presets, scenes or the workspace did not cause any problems, there’s a warning when you select a preset that contains a missing sample, and in the Engine page the sample name is prefixed with !!!, but presets, scenes and workspace load just fine even when samples are missing.

@Sandroid it appears the behavior related to length of filenames is not by design, correct?

[Sandroid]

@Lizard-of-Oz

it appears the behavior related to length of filenames is not by design, correct?

I’ll see if i can find out more , but yes - it is possible that there are filename limitations set in place by Polyend to prevent running into the overall filepath limitation.

I’ll update y’all once i know more.

[Lizard-of-Oz]

Thanks. Would that then change the opinion that this is

a) by design and
b) not a bug?

[Sandroid]

If there are soft limitations put in place, it would still be technically by-design, with room for improvement . As it would be nice to inform the user about this behaviour.

Let’s see what i can find out

[Lizard-of-Oz]

So, the topic’s closing automatically in 4 hours, and we still don’t know what the limits are.

So I opened a new bug, maybe then we’ll find out more.