apps-gworkspace icon indicating copy to clipboard operation
apps-gworkspace copied to clipboard

Published 20 hours ago • verified publisher icon gnustep

moving a directory into a remote location results in data-loss

Open eukara opened this issue 3 years ago • 8 comments

This is a critical bug and involves data loss.

I've tried this with NFS directories and SSHFS.

This can be reproduced on GWorkspace 1.0 and -git, with GNUstep's -git as well as the tarballs for Make v2.9.0, Base v1.28.0, GUI v0.29.0, Back v0.29.0

Steps to reproduce:

  1. Create a directory with some dummy files in it on a local hard disk drive.
  2. Cut or copy the directory into a remote location, either one mounted via NFS or SSHFS.
  3. You will discover that only the directory has been moved, and none of the files within, as well as sub-directories, exist.
  4. If you cut the directory from the local location, you will experience data loss.

Notes: Running GWorkspace in a Terminal does not output anything of note.

eukara avatar Sep 23 '22 18:09 eukara

Using current git and GWorkspace, I could not verify this bug. I moved and copied files and directory from local to NFS.

I wrote you an email with some proposed tests.

As you describe the issue, it could be a permission problem or a deeper bug. Could you inspect the directory that was created? does it have permissions? If you then manually try to copy inside a file, does it work? (i.e. just copy, so you don't loose your data and since the content fails, copy the content afterwards). Furthermore there seems to be an atomicity problem where a delete is performed when it shouldn't, but first we need to understand where the issue is happening.

rmottola avatar Apr 17 '24 18:04 rmottola

@eukara did you do further testing? can you reproduce? Did you try current release of gnustep libraries and git version of GWorkspace?

rmottola avatar Jun 05 '24 18:06 rmottola

Put some time aside today to rebase against the libraries. Wasn't sure what was going wrong at first since I had seemingly removed the previous versions, but some leftover frameworks/bundles still wanted to link against the old -base real bad. Despite ldconfig and all that.

Will be testing and report everything during the meeting + update here.

eukara avatar Jun 07 '24 19:06 eukara

Latest libraries and Workspace on Slackware 15, with gcc and not the new ng-runtime etc. I'm still experiencing the issue unfortunately. Folders copy, but nothing within them - so cutting them will result in data loss. I've also restarted the NFS exports and only gave them the rw and squash related flags so I could write to them, and toggled the default of no_subtree_check to subtree_check. No luck.

I will keep digging, and start debugging NSFileManager to the best of my ability.

eukara avatar Jun 08 '24 20:06 eukara

@rfm Could this be an NSFileManager bug?

gcasa avatar Sep 14 '24 19:09 gcasa

I think the thing to do to find out would be to write a minimal testcase to reproduce the issue. Try it between places on a local filesystem and vheck against OSX behaviour.

Could be there's an oddity with NFS behaviour, but dealing with that could be in NSFileManager itself or it could be in the way GWorkspace is using it (particularly how it handles callbacks).

On 14 Sep 2024 at 20:32, Gregory Casamento @.***> wrote:

@rfm Could this be an NSFileManager bug?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

rfm avatar Sep 15 '24 09:09 rfm

I tried hard reproducing this with NFS storage and was not able too.. I tried moving lots of megabytes and files on two different NFS servers! I imagine a data-loss situation could happen if remove of source happens either not receiving proper confirmation of copy or for some reason copy happened, but is not correctly written, finalized or flushed on the NFS server. It could even be a NFS bug of the client or server of @eukara's setup.

  1. either somebody else can reproduce it (I was unable to)
  2. it can be reproduced in a different setup (e.g. copying to USB disk or similar)
  3. a consistent procedure to reproduce it with Gworkspace
  4. ideally a minimized testcase to reproduce it without GWorkspace to confidently proof it is base and look it up with @rfm

Host and Server OS's of @eukara's setup? NFS version? are there VMs involved? strange local-remote mapping of network, like server being on the same pyhsical machine of the client?

otherwise nothign can be done on this issue for now.

rmottola avatar Sep 15 '24 21:09 rmottola

I will see if I can write a minimal test for this. Some of my personal machines use nfs shares so I should be able to. If it doesn't fail for me then @eukara might have to test

gcasa avatar Sep 16 '24 13:09 gcasa