Bug reporting

[supman8899]

i use 11.20. if the source file name have a 'space' or a 'dot' at the last character of a filename then ffs will not work indicating chown failure on target. please fix this asap/

[Zenju]

Error message?

[supman8899]

EPERM: Operation not permitted [chown]


and i am not allow to donate for a full edition as i am from singapore.

[supman8899]

it happens when i sync from main ssd of a imac-pro on macosx 10.14.6 to a synology ds3622sx+ raid0 drive. ssd has 4tb and snology AFP only shared has 177tb.

[supman8899]

problems occurs now with mirror function of new subdir on main ssd disk to be clone onto synlogy shared path.

[supman8899]

viewtopic.php?t=274 got it to work btw.

however, i still think it is odd that it worked if its copying to other disks while any AFP shared path fails.

[Zenju]

EPERM doesn't seem to be FFS-specific, but more a restriction of the target file system. So workaround would be to turn off "Copy file access permissions".

[supman8899]

thanks.
i would like to donate but paypal say you do not accept donation or fee from singapore.
are you able to accept bitcoin?

[supman8899]

hello?

[xCSxXenon]

No

[hspindel]

I recently discovered the neat verify file switch in GlobalSettings.xml. Running into one problem with it. I turned on verify for most of my syncs, but there are a few where I don't want verify. So I created a GlobalSettingsNoVerify.xml with verification off. I then start ffs via a desktop shortcut. That shortcut has as its target:

D:\Program Files\FreeFileSync\FreeFileSync.exe" "C:\Users\howard\Desktop\Syncs\SyncEdriveDS412.ffs_batch" "c:\documents and settings\howard\roaming\freefilesync\GlobalSettingsNoVerify.xml"


The contents of SyncEdriveDS412.ffs_batch are:

<?xml version="1.0" encoding="utf-8"?>
<FreeFileSync XmlType="BATCH" XmlFormat="23">
    <Notes/>
    <Compare>
        <Variant>TimeAndSize</Variant>
        <Symlinks>Follow</Symlinks>
        <IgnoreTimeShift/>
    </Compare>
    <Synchronize>
        <Differences LeftOnly="right" LeftNewer="right" RightNewer="right" RightOnly="right"/>
        <DeletionPolicy>Permanent</DeletionPolicy>
        <VersioningFolder Style="Replace"/>
    </Synchronize>
    <Filter>
        <Include>
            <Item>*</Item>
        </Include>
        <Exclude>
            <Item>\System Volume Information\</Item>
            <Item>\$Recycle.Bin\</Item>
            <Item>\RECYCLER\</Item>
            <Item>\RECYCLED\</Item>
            <Item>*\desktop.ini</Item>
            <Item>*\thumbs.db</Item>
            <Item>\download</Item>
        </Exclude>
        <SizeMin Unit="None">0</SizeMin>
        <SizeMax Unit="None">0</SizeMax>
        <TimeSpan Type="None">0</TimeSpan>
    </Filter>
    <FolderPairs>
        <Pair>
            <Left>E:\</Left>
            <Right>\\DS412\homes\howard\edrive</Right>
        </Pair>
    </FolderPairs>
    <Errors Ignore="true" Retry="0" Delay="5"/>
    <PostSyncCommand Condition="Completion"/>
    <LogFolder/>
    <EmailNotification Condition="Always"/>
    <GridViewType>Action</GridViewType>
    <Batch>
        <ProgressDialog Minimized="false" AutoClose="false"/>
        <ErrorDialog>Show</ErrorDialog>
        <PostSyncAction>None</PostSyncAction>
    </Batch>
</FreeFileSync>


ffs runs and successfully synchronizes. When I click on the "Close" button I get a Windows popup that says:

Cannot write file "C:\documents and settings\howard\roaming\freefilesync\GlobalSettingsNoVerify.xml.87cb.tmp".

ERROR_PATH_NOT_FOUND: The system cannot find the path specified. [CreateFile]


Any idea what is wrong? Dismissing the popup doesn't seem to cause any problems, but it does seem to indicate a problem.

Thank you.

[hspindel]

I just noticed in the error popup that where it says "howard\roaming" I would have expected "howard\AppData\roaming".

Perhaps that's a clue to the problem?

[hspindel]

Umm, yes, the missing "appdata" was causing the problem.

But it's missing in my invocation line posted above. When I fixed the invocation line, everything works great. Sorry I didn't notice the discrepancy, but posting here is probably what caused me to find it.

So ignore all the above!

[xCSxXenon]

Don't hijack threads in the first place, but definitely don't fill a hijacked thread with user error

[hspindel]

Didn't realize I hijacked a thread. I thought this was a general bug-reporting thread. That's what showed up when I searched.

[Narziss70]

Comparison results panel collapses to a sliver after restart; expanded state not persisted

Version: 14.11 (Donation Edition)
OS: Linux (path: /home/luca/)

Steps to reproduce:

Open a configuration (e.g. local folder ↔ SFTP remote).
Run Compare.
The bottom comparison results panel shows only a tiny grey vertical rectangle (collapsed state).
Double-click the rectangle → the panel expands and correctly shows the file list (e.g. 1 file to sync).
Click the small triangle next to the sync buttons → "Save as default".
Close FreeFileSync and reopen it with the same configuration.
Expected behaviour:
The comparison results panel should remain in the expanded state (showing the file list with unchanged/synced counts) after restart, since the layout was saved.

Actual behaviour:
The panel is collapsed back to the tiny grey rectangle. The "Save as default" action does not persist the expanded state.

Screenshot attached.

[Zenju]

Comparison results panel collapses to a sliver after restart; expanded state not persisted

Fixed this and other GUI glitches caused by the recent wxWidgets update:
https://www.mediafire.com/file/idq586abikeupdv/FreeFileSync_14.12_beta_Linux_x86_64.tar.gz

[Hannes_R]

Hi, I have a vibe-coded build script to build FFS on Raspberry Pi OS. It stopped working with 14.12.
The agent has identified the issue and created a new patch for my script (build is still running). According to the agent, it is a regression, so I wanted to report it:

Linux build regression in 14.12: zen/string_traits.h fails with wxWidgets 3.3.3 due to ambiguous wxCStrData conversion

Summary
FreeFileSync 14.12 fails to compile on 64-bit Raspberry Pi OS when built with wxWidgets 3.3.3.
The failure is in zen/string_traits.h. wxString::c_str() returns wxCStrData, which is convertible to both const char* and const wchar_t*. The new 14.12 overload-based character-type deduction is therefore ambiguous.
FreeFileSync 14.11 contained a HasConversion<S, Char> implementation that handled this exact wxString/wxCStrData case correctly.
Environment
FreeFileSync: 14.12 source packageOperating system: Raspberry Pi OS / Debian 13, 64-bitArchitecture: aarch64Compiler: GCC / g++C++ language mode: -std=c++23wxWidgets: 3.3.3libcurl: 8.22.0libssh2: 1.11.1
libcurl 8.22.0 builds successfully and is not involved in the failing translation unit.
Actual result
Compilation fails while compiling application.cpp.
Compiler output:
In file included from ../../zen/string_tools.h:11,
from ../../zen/i18n.h:9,
from <command-line>:
../../zen/string_traits.h: In instantiation of
‘class zen::impl::GetCharTypeImpl<wxString, zen::impl::StringType::class_>’:

../../zen/string_traits.h:60:41: error:
call of overloaded ‘conversionType(wxCStrData)’ is ambiguous

using Type = decltype(conversionType(std::declval<S>().c_str()));

The ambiguity arises because wxCStrData can convert to both:
const char*
const wchar_t*

The 14.12 source defines both corresponding overloads:
static char conversionType(const char*);
static wchar_t conversionType(const wchar_t*);

Expected result
FreeFileSync 14.12 should compile successfully with wxWidgets 3.3.3, as FreeFileSync 14.11 did.
Regression details
FreeFileSync 14.11 used independent conversion checks and deliberately preferred wchar_t:
template <class S, class Char>
class HasConversion
{
using Yes = char[1];
using No = char[2];

static Yes& hasConversion(const Char*);
static No& hasConversion(...);

public:
static constexpr bool value =
sizeof(hasConversion(std::declval<S>().c_str())) == sizeof(Yes);
};

using Type = std::conditional_t<HasConversion<S, wchar_t>::value, wchar_t,
/**/ std::conditional_t<HasConversion<S, char>::value, char, void>>;

This is especially notable because the FreeFileSync 14.11 source comment specifically mentions that wxString::c_str() returns wxCStrData and is implicitly convertible to both pointer types.
Suggested fix
Retain the FreeFileSync 14.12 StringType class/view/C-string refactor, but restore the non-ambiguous conversion test for StringType::class_.
For example, add the following helper in namespace zen::impl:
template <class S, class Char>
class HasConversion
{
using Yes = char[1];
using No = char[2];

static Yes& hasConversion(const Char*);
static No& hasConversion(...);

public:
static constexpr bool value =
sizeof(hasConversion(std::declval<S>().c_str())) == sizeof(Yes);
};

Then replace this FreeFileSync 14.12 line:
using Type = decltype(conversionType(std::declval<S>().c_str()));

with:
using Type = std::conditional_t<HasConversion<S, wchar_t>::value, wchar_t,
/**/ std::conditional_t<HasConversion<S, char>::value, char, void>>;

The conversionType() overload declarations can then be removed.
Workaround
A local patch restoring the FreeFileSync 14.11-style conversion test resolves the wxCStrData compiler error and allows compilation to proceed past this point on aarch64 Raspberry Pi OS with wxWidgets 3.3.3.


Update: Applying the HasConversion-based workaround resolves the original
wxCStrData ambiguity. The build now progresses substantially further, including
compiling application.cpp and multiple afs source files.

Compilation later stops at a separate FreeFileSync 14.12 compatibility issue:
libssh2_wrap.h references LIBSSH2_ERROR_STORE_OVERFLOW, which is absent from
the official libssh2 1.11.1 headers used by the build.

[Zenju]

You need wxNO_IMPLICIT_WXSTRING_ENCODING.

[Hannes_R]

Confirmed, thank you.

Adding -DwxNO_IMPLICIT_WXSTRING_ENCODING to the FreeFileSync Makefile C++ flags resolved the wxCStrData ambiguity without patching zen/string_traits.h.

FreeFileSync 14.12 now builds and links successfully on aarch64 Debian 13.6 (trixie), using the stock Debian GCC 14.2.0-19, wxWidgets 3.3.3, libcurl 8.22.0, and libssh2 1.11.1.

I had previously applied a local string_traits.h workaround, but removed it for the validation build. The build succeeds with the define in place.