<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div>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.<br><br>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. <br><br>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:<br><br></div>Folder A: files, many, long filenames, unusual characters, subfolders<br></div>Folder B: links to subset of Folder B + many other folders, long names etc.<br></div>Folder B: links renamed one way<br></div>Folder A: files renamed another way<br></div>Copy: Folder A files, including some of those linked, to Folder B<br></div><div>(effectively, to replace the links with the actual folders the links pointed to)<br></div>Thunar: "You want to replace these links with these files?"<br></div>Me: Yes<br></div>Files: gone.<br><br></div>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.<br><br></div>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.<br><br></div><div>| BIG IDEA |<br></div><div><br></div>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).<br><br>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.<br><div><div><div><div><div><div><div><div><div><div><div><div><div><div><br>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.<br><br><br><div class="gmail_extra"><div class="gmail_quote">On 23 January 2016 at 18:25, Weedy <span dir="ltr"><<a href="mailto:weedy2887@gmail.com" target="_blank">weedy2887@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span><p dir="ltr"><br>
On 20 Jan 2016 6:43 am, "jEsuSdA 8)" <<a href="mailto:listas@jesusda.com" target="_blank">listas@jesusda.com</a>> wrote:<br>
><br>
> El 19/01/16 a las 22:18, Heinz Diehl escribió:<br>
><br>
>> The bug is ugly as hell, and it doesn't look like it will be<br>
>> fixed in the near future.<br>
><br>
><br>
> Why this critical bug will not fixed in the near future?</p>
</span><p dir="ltr">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.</p>
<br>_______________________________________________<br>
Xfce mailing list<br>
<a href="mailto:Xfce@xfce.org" target="_blank">Xfce@xfce.org</a><br>
<a href="https://mail.xfce.org/mailman/listinfo/xfce" rel="noreferrer" target="_blank">https://mail.xfce.org/mailman/listinfo/xfce</a><br>
<a href="http://www.xfce.org" rel="noreferrer" target="_blank">http://www.xfce.org</a><br></blockquote></div><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>