Long filename fail

This bug might be more manageable if the error report offered to 'Open Containing Folder', and so to take some of the pain out of manually finding and them renaming each of the files FFS can't process by finding seven characters that can be removed from each. That really would be quite a nice temporary fix.

Actually, no. That wouldn't be enough. It's a pain even when you do find the right folder, having to find the right file.

FFS presents the filename with the full path, which since its long, is hard to read, in a way that can be read easily only by machine readers and savants. Then you have to find the folder. Then you have to find the file. Then you have to find seven characters to remove from its name.

This is one of those Linux Living Hell bugs.

This is one of those Linux Death by a Thousand Bugs.

A reasonable temporary workaround would involve offering the user a filename rename dialogue, with some sort of indicator showing how many characters still need to be removed, and some sort of apology.

Bizarrely, it cannot process files 249 characters long.

Yet when you rename a longer filename it has rejected, down to 251 chars, FFS appears to accept accept it when you tell it to <retry>.

This not only makes it impossible to work out the maximum filename it can cope with (so you can do a separate file search to get a convenient list of files and paths it cannot process, to make this task a little less like damnation) , but also raises the horrible prospect that FFS has simply put the renamed files to the end of its processing cue and I shall have to find each of them again and rename each of them again later when FFS tries and fails to process them again using whatever mysterious limit it is working by.

If you need me, you will find me in Bedlam with my hands tied behind my back, recounting these experiences to a damp wall, in Dutch.

The <retry> function has some very odd behaviour.

Here's a good game - guess the FFS filename limit:

The following test shows the filename length of files FFS said were too long to process. In each case I removed a number of characters then told FFS to <retry>.

As long as any number of characters is removed from the filename, FFS will accept the renamed file, even if its length is greater than other files it has rejected.

If no characters are removed and FFS is told to <retry>, FFS will reject it, even if the filename length is less than other files it has accepted.

Filename FFS can't process 255 chars
Filename after characters removed 250
FFS reaction on <retry> Accepted

Filename FFS can't process 253 chars
Filename after characters removed 251
FFS reaction on <retry> Accepted

Filename FFS can't process 248 chars
Filename after characters removed 247
FFS reaction on <retry> Accepted

Filename FFS can't process 251 chars
Filename after characters removed 251
FFS reaction on <retry> Not Accepted

Filename FFS can't process 251 chars
Filename after characters removed 250
FFS reaction on <retry> Accepted

Filename FFS can't process 252 chars
Filename after characters removed 251
FFS reaction on <retry> Accepted

Filename FFS can't process 248 chars
Filename after characters removed 257
FFS reaction on <retry> Accepted

Bearing in mind that each filename I have to manually edit so FFS can process it sends just a little bit more of my career down the pan and my life a little bit farther on its banal path to oblivion, I am still unable to determine what maximum file length FFS can cope with. So I can't yet take my file system to one side, catalogue all those files of that length, and rename each individually. I shall have to do a Google search, the prospect of which looms like a vortex.

FreeFileSync does not have any limit on file path length, but your file system might have one, as is apparently the case here. You can disable FreeFileSync's "fail-safe file copy" to not create ffs_tmp files, but that's probably not a good idea since that's a protection against data corruption in case of unexpected interruptions like power loss or network drops.

Oh dear Kafka.

Don't tell me it's not file length that FFS measures but path length?

You do realise I am a user? I think in terms of file length. Path lengths mean nothing to me. They mean nothing to anyone but software programs, software programmers and system administrators.

And what's the maximum path length FFS can handle? It doesn't say. Not in the obvious places, anyway. Its FAQ page brags about being able to handle path names "with more than 260 characters". It doesn't bother to tell you what the maximum is. That makes it less a FAQ than marketing chuff. And anyway, that seems a nonsense number because the path length on these files is about 316 to 323 chars. Hardly seems worth bragging about when the increase is so small anyway. Perhaps that's why they don't say what the actual limit is.

So what is the FFS path limit? Perhaps I should ask the big beefy bulldogs in town who laugh at you for being a loser. Perhaps I should ask the genie at the end of the bottle. Perhaps I should ask the jailor in debtors' prison. Perhaps I should ask the nymph at the bottom of the river.

> You do realise I am a user? I think in terms of file length. Path lengths mean nothing to me.
> They mean nothing to anyone but software programs, software programmers and system administrators.
Don't blame the messenger (=FreeFileSync), blame the sender (=your incapable file system; is it FAT?)

> And what's the maximum path length FFS can handle?
For all intents and purposes: Infinte (=that's a by-90°-rotated 8)

> Its FAQ page brags about being able to handle path names "with more than 260 characters".
That's a limitation for NTFS on Windows which FreeFileSync can work around unlike most other sync tools. So that's worthy of some brag. What FreeFileSync however cannot do is work miracles (=make a "no-so-good" file system behave like a "better" one). Anyway, just do the readers of your file names a favor and make them shorter; that's better for everyone.

Oh your other message slipped in without me noticing before I'd finished
writing my bug report.

I was too distracted by my words from this morning still echoing around my
head:

"Okay, but I'd better do a quick backup first..."

> You do realise I am a user? I think in terms of file length. Path lengths
> mean nothing to me.
> > They mean nothing to anyone but software programs, software programmers
> and system administrators.
> Don't blame the messenger (=FreeFileSync), blame the sender (=your
> incapable file system; is it FAT?)
>
>
No, actually, I was wrong to say that as a user I think in terms of file
length. I think in terms of filenames. Only, sometimes my system tells me I
can't use a filename (at the point at which I'm naming it) because it's too
long. I still don't think in terms of filename length because my Thunar
file browser, like FFS, doesn't bother to tell me what its limits actually
are when I run up against them.

No, don't shoot the messenger who delivers a message. But perhaps kick the
messenger asleep in the manger who didn't even bother getting on his horse.
Of all the people, forums and packages, FFS is best placed to tell me what
its limits are and why my filenames come up against them.

The file system is ext4.

> And what's the maximum path length FFS can handle?
> For all intents and purposes: Infinte (=that's a by-90°-rotated 8)
>
>
Then why is it telling me my filenames are too long?

> > Its FAQ page brags about being able to handle path names "with more than
> 260 characters".
> That's a limitation for NTFS on Windows which FreeFileSync can work around
> unlike most other sync tools. So that's worthy of some brag. What
> FreeFileSync however cannot do is work miracles (=make a "no-so-good" file
> system behave like a "better"

I'm not using Windows. Not all users are Windows users. Just like not all
linux users are sysadmins or chumps.

> one). Anyway, just do the readers of your file names a favor and make them
> shorter; that's better for everyone.
>
>
What would be better for everyone is if FFS told them on install that they
should not use long filenames* because it was a bit rough around the edges.

* (of an indeterminate length equal roughly to the length of a *long* piece
of string)

An app that blames the file system is like a workman that blames his tools.

Anyway, it looks like ext4 has no path limit but a 255 byte filename length, which delivers a varying character count depending, it seems, what chars you use. Typical linux: as user-friendly as a Harley-Davidson with a sextant.

So FFS really is best placed to tell me when I've removed enough chars so it can process my filenames - and to offer a convenient place to do it - perhaps in a file sheet that allows quick arrow-key navigation and return-initiated edits (like Windows Media Player allowed you to edit tracks back in the old days). And FFS ought to as well, since it is its own internal extensions that cause the malfunction. I already took a lot of care to ensure my filenames were within the limit. It would surely be simple for FFS to store its "fail_safe copy" tmp files in two parts, one handling any overspill in the filename caused by its quaint extensions?-) (quaint - tee hee).

So the answer, in short, is that their is no answer but a different answer for every individual file. And only FFS can answer it.

> FFS is best placed to tell me what its limits are and why my filenames come up against them.
I have to disagree, FreeFileSync just forwards what it is told by lower-level system components, it does not create the error messages itself. Instead it adds significant detail to the message. If FFS didn't do that, all you would see as a user is "36", good luck figuring out what that means... What you are complaining about is the scarce error reporting of system components, which historically only return error codes, because decades ago memory was an expensive resource, so they couldn't afford to add more context. If you don't like that, feel free to complain to... Linus Torvalds, maybe??

This question was expired because it remained in the 'Open' state without activity for the last 15 days.