Shouldn't put .Trash-$USER on removable devices

Bug #12893 reported by Scott James Remnant (Canonical) on 2005-02-14
This bug affects 23 people
Affects Status Importance Assigned to Milestone
Fix Released
nautilus (Debian)
Fix Released
nautilus (Ubuntu)
Ubuntu Desktop Bugs

Bug Description

I'm sick and tired of finding that my digital camera card is full after deleting
all the pictures, and my iAudio still plays deleted files.

This is because instead of deleting files from removal devices, Nautilus creates
a .Trash-$USER directory and moves the files into there.

Can we please make the default be to _not_ do this? It makes (some) sense for
the main drive, but removable ones tend to be "temporary" storage. A better
alternative would be to remove the files from the removable device and into the
user's home directory .Trash

Sebastien Bacher (seb128) wrote :

Right, that's a known upstream issue:

BTW you can use shift-del to delete without using the trash.

Daniel Robitaille (robitaille) wrote :

*** Bug 14551 has been marked as a duplicate of this bug. ***

Ramon de Ruiter (won) wrote :

In the meantime, isn't it possible to patch it in 5.04 so the default delete
action -really- deletes it? So we don't have to use shift-del, and won't have to
wait for 5.10.

Sebastien Bacher (seb128) wrote :

*** Bug 22092 has been marked as a duplicate of this bug. ***

Sebastien Bacher (seb128) wrote :

*** Bug 24541 has been marked as a duplicate of this bug. ***

lexual (lexhider) on 2006-01-16
Changed in nautilus:
status: Unconfirmed → Confirmed
Changed in nautilus:
status: Unconfirmed → Confirmed
desrt (desrt) wrote :

fwiw, the traditional argument against using the user's trash folder in their homedir is that it would take a long time to copy the files off of the usb device onto the local filesystem. flat-out delete is probably best.

Sebastien Bacher (seb128) wrote :

The question is to know if it should open the dialog saying you will really delete your files or just do it

Adam Lydick (lydickaw) wrote :

Nautilus prompts when deleting files off "network drives", I'd just have it behave the same way for the removable drive case.

Changed in nautilus:
assignee: seb128 → desktop-bugs
pirast (pirast) wrote :

This is a must fix for Dapper, although it hasn't been fixed in Gnome yet. It really confuses the end-users when they delete files on an usb stick and they do not have new free space on it and nothing is in the Trash. As mentioned above, Nautilus does have a function to delete files directly.

Sebastien Bacher (seb128) wrote :

Martin, thanks for you interest on Ubuntu. Please don't force the settings over maintainer. If you click on the Ubuntu task you will notice that the milestone is set to dappern which already means that. Letting as major since it can be considered as confusing for new users and has some duplicates now :)

pirast (pirast) wrote :

Merci Sebastien, excuse moi :-)

Clemens (clast) wrote :

There seems to be a different, better behavior in Dapper now.
The .trash-$USER folder is still being created on the removeable drive, but the "deleted" or "moved to trash" files also show up in the "global" wastebasket.
I think this behavior makes more sense.


I disagree.

I still have to have the device connected to delete the files from the trash.

And the files are still left on the device after I thought I deleted them.

Also there doesn't seem to be any way to empty the Trash of the removable device to clean it up, without losing anything important in the trash from my main home directory which I might not wish to delete yet.

Adam Lydick (lydickaw) wrote :

And this is still going to be confusing to a user coming from OSX or win32 where the behavior is immediate deletion for (most) external devices.

I think USB HD is an exception, although I don't know what fields they classify on.

loftx (tom-loftxnetwork) wrote :

I am all for bypassing the recycle bin on removable drives, though it seems like a bit of a deviation from how things work elsewhere (I don't know aboyt network drives or other not-always-available storage).

How about different delete file dialog box for removable drives with an checkbox for "Bypass the recycle bin for delated files on removable devices" so users can choose their preferred behaviour.

desrt (desrt) wrote :

Some ideas:

1) Does .Trash-desrt ever have a good purpose?
  - is created when files are not on same FS as homedir?
  - is it useful for something like /mnt/windows?
    - will this clutter up your c:\ drive?
  - maybe just never create this directory

2) Maybe don't create .Trash-desrt if the drive is on USB.

3) Maybe don't create .Trash-desrt if the drive is smaller than a certain size (2-3GB?)

4) Combination of 2&3 (so that USB harddrives still get it created).

The answer to what should be done probably lies somewhere in the above.

Joseph Garvin (k04jg02) wrote :

This isn't just confusing for people coming from OS X and Win32, but also for Ubuntu users who plug their drives into those machines, because now there is some mysterious .Trash folder and they don't have the amount of space they thought they did. A lot of people move presentations and such through pen drives, and although they may author it on an Ubuntu machine they are very likely going to be presenting on a Windows one.

Because the windows recycle bin doesn't obey the .Trash spec, emptying the recycle bin doesn't free up the space on the pen drive either. So even how to empty the 'trash' for the pen drive is going to be inconsistent if it stays this way.

It's also probably a bad idea because most pen drives are flash based and have a limited number of writes. Creating .Trash and the file moves cause extra, uneeded writes.

This behavious has been changed. Trash is now moved to the $USER .Trash directory.

Please change to fix-released

Andrew Jorgensen (ajorg) wrote :

Duncan: Perhaps you have misunderstood the bug. The bug still exists -- a .Trash-$USER directory is still created on removable devices such as USB flash drives when "Move to wastebasket" is used on a file on that drive.

Matthew East (mdke) wrote :

Yes, the bug definitely still exists. There has been some talk on this bug of fixing this for Dapper, was there any progress? It is very frustrating to have to manually delete files in .Trash-$USER (deleted files do not show up in the trash-applet either, bug #32466).

Both these bugs have _many_ duplicates and lots of comments, so this is obviously a serious bug.


Sebastien Bacher (seb128) wrote :

Matthew, I had a look on that but the code is not trivial, if you have any patch you are welcome. I mailed upstream with some questions on the best place to hack that change but didn't get a reply yet and I prefer to get their opinion before doing that change

On Sun, 2006-05-28 at 15:36 +0000, Sebastien Bacher wrote:
> I had a look on that but the code is not trivial

Ok, thanks for taking a look at it, with luck someone will come up with
a solution and it will get into a future release!


Changed in nautilus:
status: Unconfirmed → Confirmed
Bloch (aidenoreilly) wrote :

I confirm, this bug still exists.
On the forums I see cases of people thinking their memory sticks are faulty. Other people try to help, some advising to reformat etc.
This bug causes problems.

Stefan Gabriel (gabi-upb) wrote :

I confirm here as well. This bug is annoying

Sebastien Bacher (seb128) wrote :

Stefan, if you read the bug you will notice than the bug has already been confirmed so no need to comment twice saying it's annoying, people don't fix it because they don't want to, there is just many things to do for the number of people so that takes time

Stefan Gabriel (gabi-upb) wrote :

ok, sorry sebastien, i' m realy new here, i didn't notice the bug was already confirmed... you do a great job with ubuntu, thank you all

Sebastien Bacher (seb128) wrote :

no problem, thank you for your interest to Ubuntu :)

Gabriel Bauman (gabrielbauman) wrote :

I think the default Dapper behaviour makes sense.

If I put an file on my removable device into the Trash, and then walk to another machine, it's very convenient that the file appears in the trash on that machine too.

Most people are only upset about this because USB mass-storage cameras aren't handled well in Ubuntu. *Cameras and MP3 players* should not allow .Trash-$USER to exist - plain USB keys should.

Perhaps the .Trash file should just be renamed Trash? Then people can _see_ that it's there, isn't that what's most important?

I agree that by changing .Trash to Trash, and therefore making "visible" to the user, would be a bit more intuitive, but if the user clicks on the garbage bin icon (in the lower right hand corner), it will display the contents of the .Trash as well. I guess a "not so computer savy" user would most likely click on that icon that browse/search for the .Trash directory within their removable device.

Just my 2 cents.



As a quick fix / reminder I put ".Trash-$USER" read-only on my usb sticks. I get an error when I try to delete stuff with nautilus. Then I just shift-delete to delete it directly instead of move to trash.

It took me a good few hours to figure out why my second hard drive was still full after deleting everything. (everything was in the hidden .Trash-me folder)

Nautilus should instead move the file to the user's local trash (located ~/.Trash) as this would be the expected functionality and would keep the backup of the deleted files. If there is not enough room in the local drive then prompt the user saying "The file x cannot be moved to the trash. Delete them anyway? You will not be able to recover it. [Skip] [Skip All] [Delete] [Delete All] [Cancel]".

If moving the file from the removable disk to the local trash is logically impossible, Nautilus should just delete the file.

Ryan O'Connor (ryanoc) wrote :

I think it's a viable solution to move the files to the user's home directory .Trash, and this is what Dapper does now. BUT, the files aren't even deleted "permanently" from the flash disk. Can it move them to the home directory trash and clean up the unused space on the memory stick? Is that possible? By the way I don't use digital cameras or mp3 players - this behaviour is annoying the hell out of me for plain old memory sticks.

towsonu2003 (towsonu2003) wrote :

I think moving any deleted files to ~/.Trash (one central place) would be nice and solve two bugs at the same time...

From description of bug# 32466:
> When I attach an usb stick and delete some files on it. The files are moved to the trash,
> but the trash-applet still says: There are no objects.

trash-applet says "there are no objects" because it looks at ~/.Trash , which is the proper place to look. I guess this issue would be resolved if trash of removable drives is located at ~/.Trash as well, instead of /media/drive/.Trash

From description of this bug
> Ty digital camera card is full after deleting
> all the pictures, and my iAudio still plays deleted files.
> This is because instead of deleting files from removal devices, Nautilus creates
> a .Trash-$USER directory and moves the files into there.

iAudio still plays deleted files or the digital camera is still full bc the trash is created at /media/drive/.Trash - If deleted items were moved to one central place ~/.Trash, this wouldn't be a problem. The camera/iaudio would be emptied even without "real_delete_if_drive_removable" (which is a very bad idea imho).

I personnally don't think it's a good idea at all to move files from a removable device to ~/.Trash. Moving big files from USB1.0 cameras can be really long and annoying. Also, imho it just doesn't make sense to transfer files to another device when the user really wants to delete them.

There has to be some more creative way to manage this. Quick idea: maybe a delay could be put on the delete dialog when the files are on a removable device such as camera or usb stick. (I don't like this either, but it's the lesser of two evils imo)

There should be a deeper search for a coherent and usable solution.

P.S.: No OS/WM that I know of has this behavior.

towsonu2003 (towsonu2003) wrote :

ok, what if you "unhide" /media/device/.Trash by default? It would be /media/device/Trash (is this possible with gnome?) so the user will be able to see it and understand why the camera is still full (or) why the iAudio is still playing deleted files. as long as you don't do _really_delete_those_files :)

Andrew Jorgensen (ajorg) wrote :

I don't see a problem with actually deleting the files as long as the user is warned that this is what's going to happen and asked if he's sure.

Le mardi 19 septembre 2006 à 15:32 +0000, towsonu2003 a écrit :
> ok, what if you "unhide" /media/device/.Trash by default?

what is the issue with opening the dialog mentionning the files will be
dropped and not moved to the crash and really delete them by default?

Manu Cornet (lmanul) wrote :

I agree, deleting the files directly while warning the user is by far the best compromise, just like it is done on remote locations. It removes all hidden stuff, is fast (no file transfer), clear (user can just hit Cancel if he/she made a mistake).

Andrew Jorgensen (ajorg) wrote :

I didn't realize there was already code and a dialog in use. Absolutely I think the behavior should be the same whenever Trash is not available - and Trash should not be available on removable devices.

towsonu2003 (towsonu2003) wrote :

A real-life case:
Prof Dr. Jane clicked the delete key and than (as most of us will do after our Windows experiences) confirmed a dialogue without thinking twice, and thus deleting a paper her student emailed to her a month ago. The paper was in her usb stick that she was browsing. The student's email is already deleted and purged. The student came by two days later, telling her that his hard drive was wiped and he lost that paper for good. He wants that paper back.

In Windows:
The paper is gone because Windows (afaik) deletes remote files.

In Dapper:
The paper is still in .Trash-Jane, hidden. Jane most probably doesn't know it exists.

In Edgy (my proposition):
The paper is in ~/.Trash thanks to a script that links /media/removable/.Trash-Jane to ~/.Trash once the media is inserted / mounted. This link is removed once the media is unmounted. Jane doesn't know or care how this works: the paper is recovered.

In Edgy (your proposition):
The paper is gone.

Alexander Kirillov (shurik179) wrote :

The proper place for this discussion is in nautilus mailing list or in gnome bugzilla - this is where it is likely to be read by a developer. Few nautilus developers read ubuntu bugzilla.

Luca Falavigna (dktrkranz) wrote :

*** Bug 62642 has been marked as a duplicate of this bug. ***

Wladston Viana (wladston) wrote :

I confirm this bug here. Something that shall really be looked.

One thought : to make the system delete (or copy to another trash folder) the oldest files of .trash-username folder, as more free space is requested by the user.

David Bowen (lilypatc) wrote :

Trash from removable disks shouldn't be put on the main drive as this can lead to security issues as what code may end up there!
With Nautilus go "Edit" "Preferences" and click on the behaviour tab and tick the box to "Include a Delete command that bypasses Trash.
Then when you right click on a file it will give you an option to really delete the file, with appropriate warnings of course

miro (mirobaka) wrote :

here's another suggestion no one seems to have though of. Keep things as they are, but when the user goes to unmount the drive, pop up a dialog saying something like:

"You still have files in the trash on the drive you are attempting to remove. These files will take up space on the drive. You can delete these files, move them to the trash on your local computer, or cancel and manually fix the problem"

Sebastien Bacher (seb128) wrote :

That upload fixes the problem:

 nautilus (2.17.91-0ubuntu1) feisty; urgency=low
   * New upstream version:
     - Change file management capplet category
     - Avoid showing "empty" in the tree while loading directory
       (Ubuntu: #42690)
     - Prompt for empty trash on unmount (Ubuntu: #12893)
     - Capitalize lin" in "Link to ..." names
     - Fix crashes and memory leaks (Ubuntu: #84534)
   * debian/
     - updated libgnome2-dev requirement to match configure
   * debian/patches/02_autoconf.patch:
     - updated

Changed in nautilus:
status: Confirmed → Fix Released
unggnu (unggnu) wrote :

Great idea but one problem. I am using ntfs-3g and gnome moves all removed files to the usual trash position but since the NTFS partition is on my internal hard disk and umounted only on shutdown I never got this trash clear message. The trash directory consists 15 GB on my hard disk.
Afaik the KDE Trash searches every media for .Trash or something like that and shows the stuff so it could be easily clear it. At least that should be possible for static partitions in Gnome too.

Sebastien Bacher (seb128) wrote :

The nautilus trash lists also every devices .Trash

unggnu (unggnu) wrote :

But not the /media/DEVICE/.Trash-$USER directory, at least on my Feisty system.

unggnu (unggnu) wrote :

Ok, I have made some tests. It is very weird. The Trash seems to list the deleted external media files if opened but doesn't change the trash symbol (with paper) and the hover tells me it is empty. This doesn't happen if I delete files in my Linux partition. Another point is that the Trash seems to completely ignore .Trash-$USER on ntfs-3g partitions. It doesn't list any file at all. Should I made a separate bug report to keeps things clear?

Enola, this bug report is 'Re: Shouldn't put .Trash-$USER on removable devices' so if you're device is not removable you should be commenting on another bug than this one. As for the undeletable items - try emptying the users .Trash directory as root and see if that fixes it. Either way this bug is not the place for your problems, please open a new bug or support request if you need to.

unggnu (unggnu) wrote :

Ok, I have made one for ntfs-3g .
But since the problem with the hover and symbol seem to happen only with external media this should be the right place. Could anyone confirm this? Removing files on external media have no effect on the symbol of the trash (if it is full it should show the paper in trash) and the hover, which tells me that it is empty but if you open the Trash it shows the deleted files of external media. Maybe it happens with every not system/home partiton too but I have only one so couldn't check it.

Isopogon (isopogon) wrote :

The "Prompt for empty trash on unmount" feature seems to have disappeared in nautilus

This was working for other people too, but has since stopped, as shown in this thread:

Joel Parker (jjkp) wrote :

Just for the record, Windows Vista keeps deleted files on flash drives in a hidden folder called $Recycle.bin (or something to that effect), and the main Recycle Bin icon on the user's desktop then shows that it has something in it.

Windows' behavior has one other benefit: you can set maximum sizes for these for different types of storage - for example, you could set a 2GB maximum on the local recycle bin, but a 512MB maximum on any remote recycle bins.

Wladston Viana (wladston) wrote :


That is true. But when the disk is full because of the trash, and the user wants to put something on it, looks like Windows Vista automatically empties or transfer the trash, so the user don't notice that the trash was there taking some space.

In Ubuntu, it will only say that the drive is full, even if there is nothing in it but trash (that is not visible to the average user). So it's really weird, the drive appears as clean, but there is no space on it. This is the real bug on the way Ubuntu manages trash, imo.

pirast (pirast) wrote :

Plus, when using the drive on different Ubuntu installations with different Ubuntu installations, the user only can clean his trash and not the one from the other user.

I believe that the best and easiest solution would be to directly delete files on the usb storage device with the message that appears when deleting the .Trash-$USER folder on the drive. But maybe we should better discuss upstream with the GNOME developers.

i hate this bug...
it happens on others system's partitions ...

Ramon de Ruiter (won) wrote :

This bug seems to have stalled a bit.
Could someone from Gnome perhaps throw up a ball concerning comment 58? Seems like a sane thing to do.

I know everyone has an opinion about this, and i think it doesn't really matter what solution is chosen, as long as one gets chosen :)

Mike Siegel (siegelmike) wrote :

Yes, comment 58 and 59 seem like good proposals. Any updates on this one?

Sebastien Bacher (seb128) wrote :

Ubuntu does basically what is described in those comment, there is a .Trash on the volume

Ramon de Ruiter (won) wrote :

I know there is a .Trash on the volume. What i meant was a (system-wide?) setting for a maximum size of the .Trash directory on mounted usb volumes.

Changed in nautilus:
status: Confirmed → Fix Released
Wladston Viana (wladston) wrote :

wow, very elegant solution you guys came up with. Congratulations!

I disagree that this is fixed.

It doesn't the solve the problem where you delete files off a storage device, but there's still no free space to copy new files on. You can't empty the trash on a disk-by-disk basis.

Changed in nautilus:
status: Fix Released → Confirmed

(It's also nowhere near high priority :p)

Changed in nautilus:
importance: High → Low
milestone: ubuntu-6.06 → none

The problem cannot be reduced to a wide system setting. Here we talk of removable media, it meens you take it and plug it wherever you want on multiple PCs. If you don't want a .Trash on your usb stick, you don't want it whatever the Ubuntu where you plug it. It means that what is needed here is a configuration file on the USB stick to prevent the .Trash creation. You can also imagine other settings like preventing the automounting of the volume. I get multiple Ubuntus and it's what I need.

Just a little thing: A few months ago i did’t knew, that this bug exists (well, some people call it a feature, but if it’s not and optoin, its a FEARture, vulgo: a bug *g*), and deleted some stuff. The time goes by and i didn’t rememberred this .Trash-user folder on my stick. i gave my stick to another person, and the fist thing, he saw was the .Trash-user folder (because Windows don’t hides folders started by a dot), and - of course - opened it. It was kinda embarrassing for me, that a co-worker saw me in somewhat awkward positions ...

Tha fact, that there is a .Trash-user folder on the drive should be communicated more and made totally clear to the users, or there should be no .Trash-user folder at all.

Joel Parker (jjkp) wrote :

Yes, that's happened to me as well. A classmate loading a presentation from my USB drive with a running projector, and navigating into my .Trash folder because it wasn't hidden on Windows (in front of everyone). Could have been more embarrassing than it was.

I would vote for a default "deletions from an external drive are permanent" setting, or some other set of changes that make dot-folders hidden on FAT32 drives.

Brent Newland (brent-newland) wrote :

This bug is also very annoying. I delete songs on my MP3 player but... hold on... WHY is it still playing!? That's right, there's a hidden folder. It doesn't prompt me to empty the trash when I mount or unmount it, which would be a lot better.

Volodya (volodya) wrote :

When i unmount USB harddrive it prompts me if i wish to delete the files currently in the trash.
Nautilus 2.22.2

pirast (pirast) wrote :

But not if an other user put files to the Trash and has not removed them at unmount time. When you unmount it then, you do not get such a message. And that is what this bug report is about. Sadly there since 2005.

Andrew Jorgensen (ajorg) wrote :

Actually it also doesn't happen if the user unmounts the volume from a nautilus browser window instead of from the Desktop. It seems the fix they put in was put into the nautilus desktop code rather than the gnome-mount code. This should be corrected.

Changed in nautilus:
status: Confirmed → Triaged
Glauco (glauco-hass) wrote :

I agree with this bug's title, removable devices shouldn't have a .trash folder on it. At least I must to have an option to choose if the folder will be created or not.

Vadim Peretokin (vperetokin) wrote :

Isn't this already fixed? You get prompted to clear the trash at unmount.

Changed in nautilus:
status: Confirmed → Fix Released
Changed in nautilus:
assignee: desktop-bugs → seb128
assignee: seb128 → desktop-bugs

Closing since this is fixed. Thanks for reporting

Changed in nautilus:
status: Triaged → Fix Released

On Thu, 2009-01-22 at 19:57 +0000, Martin Mai wrote:

> Closing since this is fixed. Thanks for reporting
> ** Changed in: nautilus (Ubuntu)
> Status: Triaged => Fix Released
This is not fixed.

 status triaged

Scott James Remnant
<email address hidden>

Changed in nautilus:
status: Fix Released → Triaged

I am sorry, Scott, I see what you mean, because the fix is just a workaround (It prompts the users). But if this workaround is not appropriate, I think a new upstream bug should be filed about that. Do you agree with that?

elijah (shillet) wrote :



Vadim Peretokin (vperetokin) wrote :

Press Ctrl+H, you'll see all data - select it all, and do Shift+Delete.

elijah (shillet) wrote :

thank you.

Bill Smith (bsmith1051) wrote :

FYI - I just submitted bug 362050 to complain about the leftover .Trash folder.

Artyom Zorin (azorin) wrote :

Yes, I have used 3 SD cards from different brands, it created a corrupted .Trash folder and the only way to write to those SD cards is to use Windows.

matiu (matias-confronte) wrote :

Please, remove the .Trash-$user in removable drives, completly, is an incredible pain in the ass for
human users.

matiu (matias-confronte) wrote :

Please, remove the creation of the .Trash-$USER folder
in removable drives, completly, is an incredible pain in the ass for
human users.

jacare (valentimamadeu) wrote :

Please, remove the creation of the .Trash-$USER folder
in removable drives, completly, is an incredible pain in the ass for
human users.


Fabian (fabian-hiller) wrote :

The fix from upstream is that the user is prompted to emtpy the trash when the drive is unmounted. This fix is in Karmic, but a big problem is that this dialog is not triggered when ejecting a drive in Nautilus, only when unmounting.

In Nautilus "ejecting" is the default action, "unmounting" is only accessible through a context menu. Most users therefore probably never encounter this dialog. The obvious fix (to me) would be to also trigger the dialog on eject, not only on unmount (Although I really don't know the difference between these two actions).

cameleon (el-cameleon-1) wrote :

I think a new bug should be filled for last Fabian comment: the trash is not deleted when the flash drive is ejected of safely removed.
However, the best option would be in my opinion to never create a trash on flash drive, as requested here:

deew (dee-wykoff) wrote :

Workaround - create blank files on the removable drive named ".Trash-1000", ".Trash-1001", and so on as needed. Since it cant create a folder because a file already exists with the same name, it asks if it can permanently delete. At least this worked for me with a FAT32 SD card.

Kind of awkward having to copy those files to every usb drive or SD card I have, but it is less annoying than the default behavior.

I only post this because this is where Google brought me and so it is probably bringing others here.

Ryan Daly (daly-ctcnet) wrote :

I don't get prompted to clear the trash at unmount... Still getting a .Trash-<UID> created. I'm running...

Distributor ID: Ubuntu
Description: Ubuntu 10.04.1 LTS
Release: 10.04
Codename: lucid

WeatherGod (ben-v-root) wrote :

Ryan, just curious, is this a fresh install of Ubuntu with a fresh user account? Not saying that it justifies this bug still existing, just wondering why it still happens.

Ryan Daly (daly-ctcnet) wrote :

It is definitely not a fresh user. The user ID that I've been using has been around for a while. (Are you thinking maybe some legacy configuration settings are causing this?)

Also, the install of 10.04 was performed via do-release-upgrade. Prior to that, I believe 9.04 was the version that I installed from scratch.

Simke (jelax) wrote :

Il 07/08/2010 23:07, Ryan Daly ha scritto:
> It is definitely not a fresh user. The user ID that I've been using has
> been around for a while. (Are you thinking maybe some legacy
> configuration settings are causing this?)
> Also, the install of 10.04 was performed via do-release-upgrade. Prior
> to that, I believe 9.04 was the version that I installed from scratch.
Sono più di due anni utente di linux-ubuntu ed e vero che ultima distro
ho installato tramite aggiornamento da 9.04.ogni tanto mi succede che
scarico delle fotografie da macchina fotografica si e bloccato, ma in
verità solo rallenta moltissimo perché su macchina fotografica avevo
anche alcuni filmati.E per questo motivo che rallenta, ho capito
dopo.Altrimenti mio ubuntu funziona perfettamente, anche se ho un
computer vecchio con soli 1 GB di RAM e vecchia scheda madre e processore.
Vi ringrazio moltissimo per la vostra attenzione e vi porgo i miei
sinceri amichevoli saluti!
Zoran Simonovic

Changed in nautilus:
importance: Unknown → Wishlist
Scott Lewin (sclewin) wrote :

There needs to be a separate way to empty the trash on the volume. At the moment I am forced to empty the main trash can which I do not like to do very often.

entonjackson (aj-mysc) wrote :

Can't believe this awful annoying bug is still present after 6 years... very sad to see...

kao_chen (kaochen2) wrote :

The bug is still present on a fresh install of ubuntu 11.10

If I delete a file or a folder on my USB key he reappears in the folder /media/KAOKEY/.Trash-1000/files/
If I retry to delete him directly from the .Trash-1000 he reappears with a news extenstion, file.txt becomes file.2.txt. It's endless.

Only a "rm -r" or a shift+suppr erase finaly the files.

It's very confusing for new users.
Kind regards

kao_chen (kaochen2) wrote :

This is really necessary when your key is full , you don't have to eject your key before having more space

entonjackson (aj-mysc) wrote :

I'm using Ubuntu for years now! This is on of the TOP5 Bugs to me overall on Ubuntu.
It's not so bad to me, but telling people that are new to Ubuntu, that they have to delete their files on their drives by pressing Shift+Del makes no fun.

Is it so hard to implement this? What is the reason, this is only on "Whishlist"?

pirast (pirast) wrote :

just empty your trash. easy.

entonjackson (aj-mysc) wrote :

what if i forget to empty the trash.
unmount and some other mount it again.
will the trash be recognized?

What people seems to not understand it's that it's counter-intuitive to pretend that a user must be aware of the destination of it's removed files and moreover that it doesn't free its key space as expected.

When you delete files, there are two reasons: the file is useless + you don't have enough storage. This is particulary true on removable storage which have fewer space than HDD.

So, no, getting a trash on the key is not a solution, and asking for user to empty their unknown trash neither.

We need to start from the real need of a trash. It is for give the user the ability to undo its deletion. Do this undo must really last when the key is removed? Perhaps it depends on the size of the removable storage: a removable HDD is more expected to have a trash than a small flash key.

The only problem in fact from the start of this bugreport is that we don't even have the choice to have or not to have a trash folder on our media. This choice has been made a day and keep plagging everyday use of number of users without any settings to prevent this behavior (system wide or media specific setting).

entonjackson (aj-mysc) wrote :

I would at least suggest the way, that everyone can choose to have a trash or not have a trash on removable devices.

If it's so hard to implement this, then at least ASK the user when ejecting, if one wants to empty the trash.
Or... if the user wants to copy files on the removable device and there is not enough space, because of the files in the trash, then ASK, if trash should be opened.

Changed in nautilus (Ubuntu):
status: Triaged → Fix Released
André Pirard (a.pirard) wrote :

Тhere is on the other hand a high number of discussions of guys now trying to make a volume trash.

The solution looks very simple to me.
Instead of automatically creating .Trash-nnnn directories with possible permission problems to do so,
make it a partition formatting user option to "create a trash" (term he understands) and then create
drwxrwxrwt root root .Trash
Note the sticky bit t.
If .Trash exists when deleting a file, a nnnn trash subdirectory is created without permission problem.

It might be easier to see a per volume trash than display by list sorted by original location.
Ejecting the volume may indeed offer to empty the trash, but only of the ejected volume.
It's even recommended if the volume is liable to be mounted on another system with different uids.
Trash creation/removal may of course occur after formatting as a Nautilus function.

I notice that the Trash applet does not see the volume trash of the boot partition when its /home is a symbolic link to the mount point of a volume.

Changed in baltix:
status: New → Fix Released
André Pirard (a.pirard) wrote :


Felipe Figueiredo (philsf) wrote :

This bug is more than 10 years old, and all the other projects are marked as Fix Released, so I just closed the last one (Baltix).

If you think it's still an issue and worth investigating, feel free to reopen the bug. If this is the case, I suggest you reopen the bug in the upstream bug tracker, where the development actually occurs. I'm sure if you work on a patch, they'll be more than happy to review it and consider merging. This way, many more projects will benefit from your work, instead of just Baltix.

André Pirard (a.pirard) wrote :

I was asking "what solution was used?" because I can't really find out if my suggestion was considered.
Do not create /.Trash-$USER directories but $USER directories in /.Trash and only if that directory exists.
So, the user chooses if he/she/it wants a trash by creating /.Trash or not when formating or with a utility.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.