I’m a bit desperate as I’ve just lost my school project due to my lack of understanding of the sea drive client software.
Context:
Just installed the sea drive v3 client of MacOS which points to my personal instance of Seafile Pro.
Upon setting up the client, I wanted to test whether the client would behave in the same way as another install I did, meaning delete a file which is dragged in the “My Library” default library, instead of within a sub-library.
Sure enough the file got deleted, without warning.
Unfortunately the file I’ve randomly picked up for testing was the worst candidate for such experiment (I feel really dumb) and despite my attempt to find it: OSX trash, Seafile web trash, etc. I could not find the file. Undoing the move operation did nothing, and using a recovery tool like disk drill also seems to yield no results. The file in question is a pages file.
If any of you have an idea me and my grades would deeply appreciate it.
PS. Im a computer scientist therefore if there’s coding or shell tool to use, I’m perfectly fine with it.
Go to your library (I guess “My Library”) in the web. Click on “History” (top right corner, clock icon). Hover over a previous version (anything before you deleted the file) of the library and click “View Snapshot” (on the right). It should allow you to download the file.
This of course only works if the file has ever actually been synced to the server.
Unfortunately this only works for what I can only call sub-libraries, where in this instance the file was dragged into one of the main pre-defined libraries, namely " My Libraries". Thus as far as I can see there is not history nor trash available
Oh I see. Then this file will never have made it onto the seafile server. Unless you are actually “inside” a library, you’re somewhat in a “no mans land”. Data in seafile is only ever stored inside libraries.
There is no way you will be able to recover this via seafile - sorry mate!
I’ve been reading the official manual, where it states that deleted stuff is moved to the system trash, thus implying that local data is moved to a temporary folder (seafile.conf - Seafile Admin Manual). Problem is that this system trash is nowhere to be found
I think macos doesn’t think that the file was deleted. From the perspective of your OS, the file was moved. SeaDrive also doesn’t think of the file as deleted, as it was put in a place that does not correspond to any location on your seafile server.
Maybe if you can figure out where SeaDrive mounts it’s filesystem, you could stop seadrive and see if the file remains? Maybe open a Library that exists in finder and (if that exists on macos) open that location in the terminal and poke around a bit there?
Ultimately I could not locate the files. I’ve tried recovery files, navigating the local OS file system, track the file movement, to no avail. Thank you a lot for your help, though; deeply appreciated.
This is a bug, and a serious one, which was already notified in forum. I believe this is a bug because after the 15th attempt at replicating the issue when trying to move a file into one of the top libraries, the software prompted me with a warning message stating whether I wanted to delete the file or not. This was the first time where the program asked such a thing. This is, instead, the default behavior in the Windows Drive client.
Anyway, the decision to automatically delete a file, as stated in Drive manual if outside the arbitrarily predefined folder is a violation of any reasonable expected behavior. I do not know who in their right mind would ever think this is a viable solution.
The tool should instead employ its own features, such as the sync error notification, the logs (where none of the aforementioned issues were recorded), and the OS trash system.
Nobody should ever execute unrecoverable delete commands of files or folders, especially where the only safety measure between normal operation and utter chaos is a flimsy pop-up window.
A slightly less unsafe approach, would be to keep the file where it is, notify the user about a sync error and let the user solve the issue. A less optimal strategy would be to trash the file, either in the OS trash or a Seadrive trash (which location should be communicated to the user). Anything but automatically delete a file.
It seems that you dragged the file out of the Seafile library storage, so that would be “user error”, as would your apparent failure to employ regular backups.
That said, I suspect the file exists somewhere on your drive… grep, or simply transversal of your directory structure should reveal its location.
Accepting the pop-up that communicates that the file will be deleted could be considered a user error, yet I would still argue that perma-delete the file is still a bad strategy, yet not a bug per see.
In this instance, the program repeatedly failed to show the warning message, which instead is the norm on the windows version. That is why this issue is a bug.
The use of backups or any strategy that would prevent such problems has little to do with the incorrect behavior of a program.
As stated the file is nowhere to be found, likely because seafile converted the file into its internal data structure representation, therefore any reasonable reference that could be employed to find it becomes useless, yet that is only my guess.
Yup, 100% agree. No other file syncing software in existence chooses to delete files without asking you, or worse, after you click NO on the prompt. Yet, this is Seafile’s behavior when you select “Do Not Sync”, and then it proceeds to REMOVE/DELETE the folder locally as well, not just on the server, which of course propagates the deletion of those files over to the other syncing stations. Insane behavior. Absolutely bonkers.
For the deletion prompt when moving a file into category folder: We’ll improve the design by just keeping the file in place but not sync. Previously we didn’t find a technical solution to keep the file in place. Recently we found that macOS’s API provides such an option.
For the “Do Not Sync” menu item, we’ll hide it since it’s not useful in Seafile’s case. This is created by macOS’s API by default.