How recover file lost when Thunar crashed during cut-and-paste?

[Mark Ballard]

It does seem the cut-and-paste shouldn't have been implemented without an
<undo> list. It would be sensible to disable it, given Thunar's present
state of instability.

Thunar's been crashing out regularly *without* losing data. I just happened
to be very unlucky to have been in the middle of cutting-and-pasting a
large file. Even this is hard to credit because Thunar usually keeps a copy
of the cut file in its source location until it's put elsewhere, and it
stays where it is if the operation isn't completed. The developers have
clearly been very careful not to implement anything casually. It's a solid,
reliable file manager. I have inherent trust in it that is hard to shake.

But there was one other incident that got me worrying the other day and
that was a bunch of files went missing while doing a drag-and-drop. I'd
started using the drag-and-drop because I didn't want to risk losing data
while doing a cut-and-paste. The drag-and-drop files just disappeared. The
situation was:

Folder A: files, many, long filenames, unusual characters, subfolders
Folder B: links to subset of Folder B + many other folders, long names etc.
Folder B: links renamed one way
Folder A: files renamed another way
Copy: Folder A files, including some of those linked, to Folder B
(effectively, to replace the links with the actual folders the links
pointed to)
Thunar: "You want to replace these links with these files?"
Me: Yes
Files: gone.

It took a while to sort that mess out from a backup I had fortunately made
a minute before. With the file structure and operations being so complex, I
couldn't be sure I'd not made a gaff. I tried to recreate the bug but
couldn't. My retry didn't have precisely the same conditions.

I've now taken to moving files by copying them with CTRL-C, then pasting
them, then double checking it's worked, then deleting the source files. But
I still trust Thunar. And I'd still rather use it than any other file
manager.

| BIG IDEA |

It just seems obvious that Thunar should have a history function as well,
so you have a complete record of what operations were done on what files,
where they went, what attributes were changed, from what to what, and so
you can undo operations on any files that are still in a matching state to
the state they were in when the given operation was performed. It would
have to be implemented as a State Explorer, or History Explorer. If you
select a state from the history list, it appears in the browser as it was,
only with a different colour/shading scheme to signify that it's an
historical snapshot, and with certain shading signifying whether that file
can be restored. And from such a state, you can opt to restore it (or part
of it, if that wouldn't introduce terrible complications).

That would make debugging easier as well - that is, if Thunar also allowed
you to export / print / report a snapshot of any given folder as well.

I would wager, btw, that the cited bug report about Thunar crashing when
renaming files is inaccurate. I've not had any trouble renaming files at
least. The multiple rename function is really quite nice. Thunar's regular
dropouts tend to happen when browsing. And they are non-fatal. It seems to
be something less specific than renaming.


On 23 January 2016 at 18:25, Weedy <weedy2887 at gmail.com> wrote:

>
> On 20 Jan 2016 6:43 am, "jEsuSdA 8)" <listas at jesusda.com> wrote:
> >
> > El 19/01/16 a las 22:18, Heinz Diehl escribió:
> >
> >> The bug is ugly as hell, and it doesn't look like it will be
> >> fixed in the near future.
> >
> >
> > Why this critical bug will not fixed in the near future?
>
> Considering eating user files is a pretty big F you and there are patches
> available (probably too ugly to ship but still) I'm more amazed that there
> isn't more core Dev comments. Or at least follow through.
>
> _______________________________________________
> Xfce mailing list
> Xfce at xfce.org
> https://mail.xfce.org/mailman/listinfo/xfce
> http://www.xfce.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.xfce.org/pipermail/xfce/attachments/20160130/4e1c9eaa/attachment.html>