NSFileManager: data loss when copying files over the network

[eukara]

Re-filing this here so we don't forget:

As discussed in the meeting, referencing gnustep/apps-gworkspace#18, it appears that copying directories* over NSFileManager results in data loss in certain environments, specifically NFS imports. The current theory is that because the underlying ownership/permissions are different due to all_squash being set on the server side, ignoring incoming user-ids as a result, will cause some higher-level mismatch that will error out the file operation.

* Single files copy fine. Directories (empty ones) copy fine. It is merely the contents of directories which are omitted.

Test case for NSFileManager is pending

[rfm]

I have tried to reproduce this without success using this simple code to copy from a directory containing two subdirectories each containing a plain text file.

[mgr copyItemAtPath: @"." toPath: @"/nfs/general/xxx" error: &err];

The copy was to an Ubuntu server with a pretty standard /etc/exports entry as follows:
/srv/nfs/share 10.211.55.9(rw,sync,no_subtree_check)

That works fine for me, and I note that in gnustep/apps-gworkspace#18 Riccardo ried to reproduce the problem using GWorkspace and was unable to do so.

So we definitely need instructions on how to reproduce the issue; exact information on what nfs set up to use etc.
I suppose it may be the case that, rather than a bug copying, this is a permissions issue on the particular machine preventing the copy, and the issue is a failure to report it well (or at all). We need instructions to reproduce the problem either way.

[gcasa]

I think what might help is if you run Gworkspace or your test case in the debugger. Perhaps it is getting some error that the calling code in nsfilemanager is ignoring. @eukara

I would suggest setting breakpoints where nsfilemanager makes low level calls to do the copy. My suspicions are similar to @rfm

It's alarming that you were able to reproduce it during the meeting. Very concerning.