Creating 0KB files

[nastye]

So I'm trying to use FFS to sync my music between Windows PC and MacBook Pro. The music is stored on a harddrive in my ubuntu "home-server". Everything works fine on the PC (mostly syncing to the storage) using SMB, but when I try to sync files TO the notebook (AFP share pointing to the same directory on the server) I only get 0KB files with the right naming and folder structure even though I can manually copy the files just fine.

[Zenju]

You're using the OS X version of FreeFileSync? Which version are you using?

[nastye]

FreeFileSync 6.14 Feb 10 2015 Unicode x64 on Windows and OS X

[Zenju]

Okay, let's find out where this difference is coming from:

Can you log two traces:

1. setup a minimal sync job, which copies a single file only and run FreeFileSync while creating a log file:

`sudo dtruss ./FreeFileSync &> ffs_log.txt`

2. this is assuming the "cp" via command line works correctly: copy the file manually:

`sudo dtruss cp <source path> <target path> &> cp_log.txt`

Then attach the two log files here or send them to me via email.

[nastye]

I'll do this in approx 6-7 hours when I'm home again.
E: Got to do this right now.
So from the looks of it the invocation of CP through DTRUSS breaks the copying aswell (Can't handle spaces in source path). I can copy just fine with only cp <src> <tar> (spaces are fine there aswell).

As for the ffs_log I started the binary of FFS directly because it wouldn't start otherwise (obviously). I then had to change the settings and start the usual two-way-sync. Ended up with several 0KB files again.

[Attachment was removed! File name: ffs_log.txt (5568046 bytes)]

[Zenju]

> (Can't handle spaces in source path). I can copy just fine with only cp <src> <tar> (spaces are fine there aswell).

Not sure if I understand you correctly: The `<source path>` and `<target path>` were just place holders for you to put actual file paths there. And if these paths contain spaces, they naturally need to be protected by quotation marks, as always...

> As for the ffs_log I started the binary of FFS directly because it wouldn't start otherwise (obviously).

Good, can you also give the name of the sample file that you synced?

[nastye]

The file i copied was
/Volumes/Media/media/Music/Eskimo\ Callboy/Crystals/11\ Crystals.mp3
OS X appropriately escapes spaces with the \ character when you drag a file into the terminal window.
I synced that whole folder, so "/Volumes/Media/media/Music/Eskimo Callboy/Crystals"

So
sudo dtruss cp /Volumes/Media/media/Music/Eskimo\ Callboy/Crystals/11\ Crystals.mp3 ~/Desktop
wouldn't work while
cp /Volumes/Media/media/Music/Eskimo\ Callboy/Crystals/11\ Crystals.mp3 ~/Desktop
would.

[Zenju]

The following syntax should work for "cp":

sudo dtruss cp "/Volumes/Media/media/Music/Eskimo Callboy/Crystals/11 Crystals.mp3" ~/Desktop


Can you repeat the trace for FFS and only sync the "11 Crystals.mp3" file as well? The old trace file partially doesn't make sense and I want to be sure to not get side tracked.

[nastye]

Nope, still not working, even with the quotes. Log looks exactly like the first time.
I had to set the folders for Sync again, so that'll probably be in the log aswell. Got another 0KB file

[Attachment was removed! File name: ffs_log_2.txt (3761848 bytes)]

[Zenju]

> Nope, still not working, even with the quotes

Can you temporarily rename the file to get rid of the blanks, then try again?

> I had to set the folders for Sync again, so that'll probably be in the log aswell. Got another 0KB file

What I meant was to sync only a *single* file only in order to simplify the log. You can do this by temporarily excluding all but a single file pair on the FFS main grid.

[nastye]

Sure.
I have synced the single file you asked for, into an "empty" folder (Desktop)

I have moved the .mp3 to a new folder and removed any spaces from the name (full path doesnt have any spaces now) I could successfully cp now, but FFS would still not work.

full path to file: /Volumes/Media/media/tempMusic/11Crystals.mp3

[Attachment was removed! File name: ffs_log_3.txt (2214607 bytes)]

[Zenju]

I just found out that "dtruss" is mixing rows at random due to "CPU buffering", which makes analysis infeasible. However there seems to be the `-d` switch for dtruss to add relative times to remedy this problem. Can you try the ffs test again with this switch? No need to retry the "cp" test, it's already short and sweet (but also mixed up).
BTW did you copy the "11Crystals.mp3" file three times in your test? I'm seeing three "open" commands, where there should be only one.

[nastye]

I don't remember copying 3 times, but I wouldn't count it out either :D

[Attachment was removed! File name: ffs_log_4.txt (796620 bytes)]

[Zenju]

After seeing the logs I have a hunch that it may be related to OS buffering. Therefore I've created a little test tool: It has hard-coded the path "/Volumes/Media/media/tempMusic/11Crystals.mp3" so before running the test, make sure that some file is available at this path. Then execute the "run_test" file from console and let me know what it prints:

[404, Invalid URL: https://freefilesync.org/OSX-test.zip]

[Zenju]

There's a second thing you could kindly test: Does the issue with 0-sized files also occur when you use FreeFileSync 6.12?
[404, Invalid URL: http://sourceforge.net/projects/freefilesync/files/FreeFileSync/archive/FreeFileSync_6.12_Mac_OS_X_64-bit.zip]

[nastye]

run_test gave the following output:

F_NOCACHE success! bytesRead ==524288
buffered: success! bytesRead ==524288
F_NOCACHE success! bytesRead ==524288

FFS 6.12 was able to sync that file to my Desktop :)

[Zenju]

Okay, the test shows the issue is not related to OS buffering, which was the major difference when comparing the trace files.
Whatever is causing trouble is present in Apple's "copyfile" API, but not in "cp".
So let's give the "cp"-based implementation another try. Let me know if you find any issues with this version:

[404, Invalid URL: https://freefilesync.org/FreeFileSync_6.15_beta_Mac_OS_X_64-bit.zip]

[nastye]

This worked. :)

[Zenju]

Excellent, this will be in the next FFS release. Thanks for the feedback and tests!