Windows Error Code 87

[eschepp]

I'm running RealtimeSync v3.17 on a Windows 7 64bit PC.
This was working fine - but yesterday all kinds of things went wrong.

The sync between the P:\folderpath\ and C:\folderpath\ caused a bunch of files
to be deleted from c:\folderpath\ that remained on P:\folderpath\.
The files have not been updated for a while - so no idea why FFS was trying to
do anything with these files.
Forunatly I have RealtimeSync setup to backup the files it deletes - so I
could move them back.

The second problem was I started getting the following error:

Error copying file:
"P:\folderpath\file.mp3" ->
"C:\folderpath\file.mp3.ffs_tmp"
Windows Error Code 87: The parameter is incorrect.

Next I upgraded to 3.21 - still the same problem.
FreeFileSync compares the folders fine - but then it fails with the error
above when trying to sync.

Anyone have any ideas what is causing this issue?

[Zenju]

>bunch of files to be deleted from c:\folderpath\ that remained on
P:\folderpath\.
FreeFileSync never deletes from one side only when a file exists on both
sides. Therefore the only chance for this happening is that a file was changed
on one side, FreeFileSync was trying to update the other file (= delete +
copy) and the copy-step failed. But this can only(!) happen, if transactional
file copy is deactivated. In all other cases, I see no possibility how
FreeFileSync could be responsible for the delete, and leave an orphan file
behind.

>The second problem was I started getting the following error:
Is it reproducible? If so I would try to copy manually, e.g. via explorer. I
would expect the same error to be shown. Something in the network setup must
have changed.

[eschepp]

Zenju - thanks for your super fast response - as allways :)

You are correct - I did a bunch of checking and testing. The files got
corrupted on one side (P: drive).
The date on the files changed so RFS made a backup of the destination files
(the way I had it configured), then deleted the destination files, then it
tried to copy the source files and stopped. Since the source files where
corrupted it could not copy them and it stopped.
Maybe a future improvement for FFS would be to make sure it can read files
before starting the sync (might slow things down a bit though).

Thanks for a great program!

[Zenju]

> future improvement for FFS would be to make sure it can read files before
starting the sync
Make sure globalsettings-> transactional file copy set to active. It's
function is to explicitly prevent this kind of situation and provide all or
nothing behavior. This avoids having a single file deleted as the result of an
interrupted overwrite operation.

[eschepp]

Cool - This is a new feature!
Will this be used by Real File Sync also if i set it in FFS?
I did not see any transaction param setting in the RFS batch file.

[Zenju]

RTS is "just" a starter for a command line, which in 99% will be FFS. It
doesn't know anything about it's target executable. But the FFS batch job
you're invoking honors this setting, of course, so it will be working.

[rainking430]

I hope it's ok if I resurrect this old thread, because I've just started using the RealtimeSync feature, and I'm getting this exact error. I'm syncing from C:\xxx\xxx.xxx to P:\xxx\xxx.xxx (which is basically a network location mapped to P:). FreeFileSync works fine, however when I set up RealtimeSync to watch these two folders it says:

Cannot monitor directory 'P:\xxx\xxx.xxx'. (ReadDirectoryChangesW)

Error Code 87: The parameter is incorrect.

Any idea why FFS handles this location fine, but not RTS? This is regarding FFS version 5.14.

[Zenju]

A new thread would have been better, since except for the error code this has nothing to do with the original topic.

Anyway, ReadDirectoryChangesW specifies to return ERROR_INVALID_PARAMETER (87) if the buffer size is larger than 64 kB and the monitored directory located on a network.
Now FFS uses exactly 64 kB, but maybe it should be strictly lower?
In order to exclude the buffer size from being the problem, I've created a new version that uses 32 kB. Let me know if this works instead:

[404, Invalid URL: http://freefilesync.sourceforge.net/FreeFileSync_5.15_beta_Windows_Setup.exe]

[rainking430]

Thanks for the quick response! Sorry about that, the OP titled this thread Windows Error Code 87, which I'm getting, so I thought my problem would be related.

Anyway, tried the beta and the error still happens.

[Zenju]

I'm somewhat out of ideas what could be the problem on this one. The call to ReadDirectoryChangesW is certainly correct, therefore there is at least also a problem with the software running on your network server which does not agree with the commands passed. It's a long shot, but there is an optional, unused parameter that FFS currently does not pass. Maybe this is what the network server is complaining about.
I've updated the link above with the new version, let's see if this does something.

[rainking430]

Nope, no go. Like before, FFS handles the location fine when syncing, but RTS still throws that error.

Maybe if I give you more detail, it might help. This path is actually to a Pogoplug connected to my network. Its basically a NAS device, except you plug USB drives into it. The big selling point for me is that it includes software called the Pogoplug Drive, which loads with Windows and makes the Pogoplug appear as just another drive letter (P:), even over the internet. 99.9% of the time it just works.

That said, there is one interesting thing about it. Even though the PP supports NTFS, and all my drives plugged into it are in NTFS format, Windows sees the P: as FAT 32. So maybe there is some trickery going on in the PP software, since all day long I can transfer and save files to it that are well over 4 GB and never have a problem. I do vaguely remember that a long time ago I used one program to save a file over 4GB to the P: drive and it threw an error that the destination on the PP appeared to be FAT32, so the file was too large to be saved. That was the only time I ever saw such an error, perhaps until now. Since then I have used several other programs to save files larger than even 20GB to P: with never an issue, including FFS which automatically syncs files that size to P: every day without incident. :-)

So, sorry for the long post, but hopefully those points might shed some more light on what RTS' problem might be and how to fix it.