Test client build 4.7.7 creates erroneous directory and file entries

[darcio]

The 4.7.7 client version introduced a pretty serious error: when copying whole directories and their contents TO the Samba share storage, if a given target directory already exists (with a matching name, but it is located somewhere else in the directory tree structure) the resulting copy operation puts the files being copied in BOTH locations, that creates a pile of a mess. I discovered this as I proceeded with my photo and video album migration to the NAS.

[darcio]

I am using the following configuration on my system:

1) NetDrive => 3.1.6.876 2) Samba plugin => ​http://smedley.id.au/tmp/ndpsmb-3.3-samba47-20170924.zip 3) Samba CLUT => ​http://smedley.id.au/tmp/smbcln47-4.7.7-20180428.zip

The issue being reported does not happen with the latest official smbclut-1_3_0-1054.zip, which is what I am currently using in order to avoid this issue.

I am reporting this though given that Paul made this build available and since I am heavily using Samba (and was previously experiencing problems with LIBcx crashes) I thought I would test this out and put that release through it's paces.

Logged the ticket here because this is the OS/2 Samba 'homepage'. Given that this is Paul's CLUT build, I am not sure who behind the scenes is actually doing what. If I need to address this with Paul only please let me know.

[Paul Smedley]

Can you elaborate more about how to reproduce, perhaps some examples of how you're copying (WPS or command line), and examples of paths on your system that lead to the scenario? Logs of course are always welcome :)

[darcio]

Paul, I thought I had a pretty consistent use-case to demonstrate this issue since switching over to the 3.6.25 clut appeared to work successfully. That result implied that your test 4.7.7 build was somehow causing the issue. However, just the other day this very symptom re-appeared even though I was using the 3.6.25 clut. That really threw me for a loop. I started to re-test with a more systemic approach, meaning, documenting the combination of: clut & ND plugin and the results these create.

Eventually what I discovered was that the issue I was seeing can be best described as a "ghost", meaning, even though the WPS Drives object shows the presence of the same files in multiple folders on the Samba share, in reality they are not really there. I was able to confirm this by looking at my NAS box and it's internal 'share browser' functionality.

Further on, when this type of an issue appears (ie. I see the same folder contents in multiple Samba share folders) and I traverse the remote share's directory structure (all using the WPS Drive/Folder functionality and selecting various share folders following by coming back to the originally selected folder) I find that the issue disappears. So this is why I called it a "ghost". I am trying to figure out how to best illustrate this in the ticket. The issue does not appear to be a sequential cause=>effect type of a problem, instead it almost appears as if a series of events are adding up to cause the behaviour I'm seeing.

At this point in time I can confirm though that it appears the clut version is not the cause here, the issue occurs using both the 3.2.65 and 4.7.7. builds. I am inclined to say this may be a ND Samba plugin issue, since using the latest 3.03.0 release has shown this behaviour, while reverting back to the 3.02.x beta build appears to not exhibit it. Please note, I say "appears" only because in my repeated attempts I have not been able to re-create this result yet, however only a limited amount of testing has been done on my end.

I think the only way for me to try to trap this is by going through this process again but this time with various LOGs turned on. I am only aware of the standard Samba log entry controlled through smb.conf and the NetDrive log.ndpsmb output. Would this be the right way to go about it?

[Paul Smedley]

Thanks for the update. I'd agree this is a possible bug in the Netdrive plugin. I'd suggest lowering the Samba logging to 0 in smb.conf and focus on getting a log.ndpsmb that shows the issue. Hopefully that will be enough to present some clues