ver 10.25 cannot handle certain characters - is there a way to d/l previous ver? (update: issue with Linux)

[vjayer]

Current version 10.25 can no longer handle ":" and "|" and probably others as indicated here:
viewtopic.php?t=7494&p=25264&hilit=filenames#p25264

This is a change compared to previous version which could handle any character the filesystem allowed. I'm on Linux and I have a TON of files and dirs that have already been sync'd with FFS previously with these special characters. The comparison phase still works with these special characters, but any sync on changed dirs/files with these chars no longer works. This essentially breaks my usage and I can no longer use FFS.

Unlike the other poster, I would not like to forcibly replace the characters but have the option to keep or replace. I think FFS should allow any character the OS filesystem allows and also have the option to replace problematic characters (i.e. universal char compatibility set). I use FFS on Windows too and the Explorer file manager won't allow certain chars so I normally don't get this issue there. It's really a problem on flexible filesystems (all the *nix ones)

Until this is fixed, can you make the previous ver 10.24 available?

Edit / update:
I'm so sorry, my issue of dealing with these special chars at least appears to stem from my recent upgrade to Linux Mint 20 with kernel 5.4.0-42. I tried the latest ver 11 and all versions back to 10.20 and it still occurs. The error is:

Error   Cannot write file " .... ~< ... >.ffs_tmp"
EINVAL: Invalid argument [open]


[TAC109]

All previous versions are available. See the 'Archives' button at the top of the main window.

[toby9999]

Note: these archived versions aren't the "donation" versions ... so, there's that.

[Zenju]

Current version 10.25 can no longer handle ":" and "|"

Except for viewtopic.php?t=7509 I'm not aware of any changes in this area.

[bobjtx1]

Zenju, I have this same issue in a different form. I am on a Mac and to get folders to list at the top of a directory on OSX (like is done in Windows), I start all folder names with a space so they sort to the top. Version 10.25 now complains that my directory name "starts or ends with a space", and throws an error. This was not an issue for previous versions. This needs to be fixed, as filesystems allow naming directories or files with these characters, and if the filesync software throws an error on allowed naming conventions, there will be errors all over the place and the software will no longer be useful.

At this point I have to roll back to the previous version, as almost all my directories start with a space character, as this version will no longer copy the files. I'll post this on the linked issue you linked to in your above noted response, so that this issue gets captured correctly.

Thanks.

[bobjtx1]

Note: I suspect others may also be using any character less than "A" (x0045) at the beginning a a directory name to force sorting directories to the top on non MS-Windows file systems. Other characters can also work (Hyphen, "!", "=", "0", etc.), but are not as visually pleasing as a simple space character.

[Plerry]

Primarily working in Windows, where a leading whitespace is not allowed (actually: ignored when entered), I use an "_" (underscore), for this purpose.
This is (almost) as visually "pleasing" as a whitespace.
It is cross-platform compatible and syncs perfectly with FFS.

I agree with you that preferably all legal file and foldernames should be supported, particularly when syncing within the same platform.
For tools that are supposed to work cross platform (like FFS) it is however always the question how to deal with platform mismatches.

By the way: you wrote
> almost all my directories start with a space character
That sort of seems to defy the purpose, unless you also vary the number of leading spaces.

[therube]

(If I'm reading correctly, he wants directories displayed before files.
And by add a space to the beginning of the directory name, he accomplishes that - where otherwise directory & files would be intermingled.
[And one would have to assume that he does not have files starting with a space.])

(The space issue is to be reverted, viewtopic.php?t=7509#p25340.)

[vjayer]

All previous versions are available. See the 'Archives' button at the top of the main window.

Thanks a lot.

I have an update:
I'm so sorry, my issue of dealing with these special chars at least appears to stem from my recent upgrade to Linux Mint 20 with kernel 5.4.0-42. I tried the latest ver 11 and all versions back to 10.20 and it still occurs. The error is:

Error   Cannot write file " .... ~< ... >.ffs_tmp"
EINVAL: Invalid argument [open]


I have a single test file that needs to be mirrored with a "|" in it. Note that most of my files with ":" and "|" are from web page titles (via saving links or web pages, which I do for all my ebooks for erratas, source code, etc). The comparison phase always works, it's the writing to the tmp files that fails. I don't know if something changed in Linux Mint 20, Ubuntu 20.04 from which it is based on, or kernel 5.4.0-42 and system calls

I can help debug and try experimental builds to narrow it down on my end

[Plerry]

If I'm reading correctly, he wants directories displayed before files.

I must be spoiled ... In Windows File Explorer that is default behavior. When sorting ascending by name (=default), directories are shown first in ascending order, followed by files in ascending order; when sorting descending by name, files are shown firsts in descending order, followed by directories in descending order.
It seems they (finally?) did something right at MS ...

[vjayer]

Ok an update:
I narrowed it down to an issue in handling of ntfs drives in the latest ubuntu lts (20.04), kernel 5.4.0, using ntfs-3g FUSE driver. Creating any file with ":" and "|" etc on these partitions returns EINVAL. Occurs with any program such as rsync or system calls, library calls such as mkstemp(). This does not occur with native ext4 partitions.

I had been using an external hard drive formatted in ntfs for backing up my linux machine which had worked all along until now. I wonder if this is an intentional change to make it more inline with Windows since the explorer file manager and most interfaces do not allow these chars