Trashing a file on Ubuntu Linux deletes it unrecoverably about trash

[sindresorhus]

Look for files named in similar fashion like 3efa1383-fba5-44c0-a2a0-ac30fcb1663e. It renames the files unique IDs to prevent duplicates. Not sure why, but I think it is to follow the Linux trash spec: https://specifications.freedesktop.org/trash-spec/trashspec-latest.html I didn't make the implementation nor do I use Linux, so I can't really be of much help here.

[roryokane]

Thanks; I found these files and folders in /home/roryokane/.local/share/Trash/files/ that corresponded to the test folders:

• 50f672ee-bd83-45f7-91b4-b12cc85e8d65, an empty file
• 074a6bca-d7b8-45fb-aeef-6717bd0c9a42, a file containing "contents of bbbbbb"
• 558156bd-08f4-4aed-95f7-edeb8c2ff39b, a folder containing foo.txt
• 8d3c831d-5e57-4d51-80f6-3fd1dc5f1700, an empty folder

I can also see these files listed at the bottom of the Trash:

DeletionDate format difference

While looking at their corresponding .trashinfo files, e.g. /home/roryokane/.local/share/Trash/info/50f672ee-bd83-45f7-91b4-b12cc85e8d65.trashinfo, I noticed a difference between the ones generated by trash and the ones generated by the OS’s file manager, in the date format for DeletionDate. Maybe this is the problem. An example file generated by trash:

50f672ee-bd83-45f7-91b4-b12cc85e8d65.trashinfo

[Trash Info]
Path=/home/roryokane/aaaaaa.txt
DeletionDate=2017-03-07T17:25:29.770Z

And an example file generated by the file manager:

eeeeee.txt.trashinfo

[Trash Info]
Path=/home/roryokane/eeeeee.txt
DeletionDate=2017-03-07T16:27:58

trash’s “2017-03-07T17:25:29.770Z” doesn’t match the date format and time zone of the file manager’s “2017-03-07T16:27:58”. trash doesn't match the spec here:

The date and time are to be in the YYYY-MM-DDThh:mm:ss format (see RFC 3339). The time zone should be the user's (or filesystem's) local time.

I’m not sure if this is the problem, because when I edit 50f672ee-bd83-45f7-91b4-b12cc85e8d65.trashinfo and paste in the well-formatted deletion date “2017-03-07T16:27:58”, then refresh the Trash window in the file manager, I still see 50f672ee-bd83-45f7-91b4-b12cc85e8d65, not aaaaaa.txt. And directories have the same wrong date format and time zone in their .trashinfos too, yet they are shown correctly. But maybe changing the date isn’t helping because of caching issues, or because of the fact that the modification time of the .trashinfo was updated. It’s one improvement, at least, even if it doesn’t turn out to be the cause.

Currently, the code creates the DeletionDate with (new Date()).toISOString(). That’s the part that should be changed to fix the date format and time zone.

[roryokane]

If you figure out the code to convert the date to a string in the correct format and in the current time zone, I can overwrite my ~/.config/yarn/global/node_modules/trash/lib/linux.js and re-perform my tests with trash, and we can see if that fixes the problem.

I didn’t see a method in MDN’s Date documentation to format a date using a format string. toLocaleString looks close, but it looks like it is only made for outputting human-readable strings, and so doesn't support adding formatting such as the “T” in the middle. You might have to add the Moment.js library.

[steelbrain]

Couldn't the JS part do (new Date()).toISOString().slice(0, 19) to match the required format?

[roryokane]

@steelbrain I hadn’t thought of that. After looking up the toISOString docs, though, I don’t think that your simple slice would always work, because the docs say that either of the following formats could be returned: “YYYY-MM-DDTHH:mm:ss.sssZ or ±YYYYYY-MM-DDTHH:mm:ss.sssZ”.

However, that makes me realize that the toISOString() polyfill provided in the docs can be tweaked to produce the desired output without needing an external library. This should work:

function pad(number) {
  if (number < 10) {
    return '0' + number;
  }
  return number;
}

// produces strings such as '2017-03-07T16:27:58'
function toShortenedISOString(date) {
  return date.getUTCFullYear() +
    '-' + pad(date.getUTCMonth() + 1) +
    '-' + pad(date.getUTCDate()) +
    'T' + pad(date.getUTCHours()) +
    ':' + pad(date.getUTCMinutes()) +
    ':' + pad(date.getUTCSeconds());
};

[Natetronn]

I'm hitting this issue as well. Was there a fix already?

[IssueHuntBot]

@IssueHunt has funded $60.00 to this issue. See it on IssueHunt

[roryokane]

Summary of the discussion so far:

• Files are not deleted unrecoverably as the title says, but rather are displayed in the Trash with a random name instead of their original filename, making them hard to discover.
• The Linux trash spec defines how to properly move files to the trash, which includes writing .trashinfo files that contain metadata about deleted files.
• I see a discrepancy in the date format within the .trashinfo files that trash generates. That date format breaks the spec, so it should be fixed, but it is unsure whether this date format discrepancy is related to the larger problem.
• My previous comment contains JavaScript code that would generate a date string in the correct format for .trashinfo files. That code should be used where the DeletionDate line is output, in linux.js on line 23.

[Okami-]

@roryokane I was able to implement your code to match the linux date spec. Thank you for the snippet.

The current code at linux.js on line 16 sets the name as an uuid. Was this on purpose?

I can match the file name being deleted and push a PR if not.

[roryokane]

@Okami- Fixing the date format can be done without much thought, but if you’re going to attempt to fix the larger issue of files being misnamed, you’re probably going to have to read through the Linux trash spec. This is because the issue is likely caused by trash deviating from the spec at some point. (Alternatively, it could be that Ubuntu’s trash deviates from the spec.)

The answer to your question is in the spec’s “Contents of a trash directory” section, paragraphs three and four.

[Okami-]

uh huh. As mentioned previously ubuntu it's self doesn't follow the trash spec as when I delete a file aaa.txt and delete another aaa.txt they both are in the trash bin named the same.

edit:
After checking /.local/share/Trash/info the aaa.txt.trashinfo turns into aaa.2.txt.trashinfo to differentiate between the two similar named files..

So I could do the same with Trash with string interpolation.

A decision needs to be made whether when a file is deleted the uuid, original filename, or a different solution is provided.

[Okami-]

const name = path.basename(filePath);

Setting the variable name to the path.basename keeps the original filename

fs.access(destination, fs.F_OK, (err) => { console.log(`${destination} ${err ? 'does not exist' : 'exists'}`); })

The code above is able to test whether the file exists or not. Just need to concatenate a file filename.number.extension if the filename exists instead of a console.log now.

[JubbeArt]

A much simpler solution could be to use the built in (on Gnome) gio trash command instead of trying to implement the specs properly. For older systems you could use gvfs-trash. And if none of those commands exist you could fall back to the current trashing implementation.

edit:
Ended up doing this for my personal project:

import { promisify } from 'util'
import { exec } from 'child_process'

const execP = promisify(exec)

export function trashFile (fileName: string): Promise<void> {
  return execP(`gio trash ${fileName}`)
    .then(() => { })
    .catch(err => {
      console.error('Could not remove file:')
      console.error(err.toString())
    })
}

Restoring files works as well

[sindresorhus]

For anyone that wants to work on this, see the discussion in #86.

[vasyl-shumskyi]

Moving files to trash also deleting them permanently on Ubuntu 20.04

[issuehunt-oss]

@sindresorhus has rewarded $54.00 to @gsittyz. See it on IssueHunt

• 💰 Total deposit: $60.00
• 🎉 Repository reward(0%): $0.00
• 🔧 Service fee(10%): $6.00