Some files cannot be deleted from Trash

[Cypress]

I found out some files cannot be deleted from Trash. Whenever I try to empty the Trash, I get an "There was an error deleting <filename>. Opperation not allowed" or "There was an error deleting <directory>. Directory not empty."

I attached an archive of those files. Extract the files from the archive, delete them and see for yourselves.

Strange thing is I can't even "rm" them from the command line and some of the subdirectories cannot be browsed from CLI.

[Cypress]

An archive of files and directories that cannot be deleted.

[humdinger]

I currently have the same effect with two folders in my Trash (alpha4.1). Zipping them up, booting another installation on another partition and unzipping and deleting them there has them deletable from Trash with no problems. So Cypress' Archive.zip probably isn't useful.

checkfs doesn't show any issues.

This is written to syslog, after trying to empty the Trash, which shows the alert: "Error emptying Trash":

KERN: bfs: bfs_access:1487: Operation not allowed

Entering KDL and entering "bfs_inode 1487" puts this into the syslog:

KERN: kdebug> bfs_inode[K 1487INODE 0x000005cf
KERN:   rw lock:           0x000005db
KERN: 
KERN: [*** READ FAULT at 0x603, pc: 0x814ec19c ***]

I'll keep those two zombies in my Trash for a while, in case Axel has some instructions to get more info.

[axeld]

Great, humdinger :-)

First of all, do a ls -lia of the trash directory. Note down the inode numbers of the trash itself, and the two problematic files. Then use the bfsinfo command like this:

$ bfsinfo -ib . <trashInode>
$ bfsinfo -i . <broken1>
$ bfsinfo -i . <broken2>

And attach the output, thanks!

[humdinger]

OK, this is the "ls -lia" output:

1048576 drwxr-xr-x 1 user root 2048 2012-12-20 17:56 trash

 545627 drw-rw-rw- 1 user root 2048 2012-12-07 02:41 Audio
 545655 drw-rw-rw- 1 user root 2048 2012-12-09 00:28 Video

This is bfsinfo for the Trash:

/boot> bfsinfo -ib . 1048576
Copyright (c) 2001-2010 pinc Software.

Inode at block 1048576:
-----------------------------------------
inode "trash":
  magic1             = 3bbe0ad9 (;...) valid
  inode_num          = (16, 0, 1)(null)
  uid                = 0
  gid                = 0
  mode               =  100040755 (octal)
  flags              = 00000001
  create_time        = Sat Oct 13 07:23:46 2012
  last_modified_time = Thu Dec 20 14:18:48 2012
  parent             = (8, 0, 1)(null)
  attributes         = (16, 1861, 1)(null)
  type               = 0
  inode_size         = 2048
  etc                = 00000000
  short_symlink      = -
data_stream:
  direct[00]                = (16, 1, 1)
  max_direct_range          = 2048
  max_indirect_range        = 0
  max_double_indirect_range = 0
  size                      = 2048
  --
small data section (max. 1816 bytes):
0x43535452 (CSTR), name = "", data = "trash", 5 bytes
0x52415754 (RAWT), name = "_trk/pinfo_le", 20 bytes
0x49434f4e (ICON), name = "BEOS:L:STD_ICON", 1024 bytes
0x4d49434e (MICN), name = "BEOS:M:STD_ICON", 256 bytes
0x52454354 (RECT), name = "_trk/windframe", 16 bytes
0x4c4f4e47 (LONG), name = "_trk/windwkspc", 4 bytes
0x52415754 (RAWT), name = "_trk/winddecor", 242 bytes

B+Tree at block 1048576:
-----------------------------------------
bplustree_header:
  magic                = 0x69f6c2e8 (i...) valid
  node_size            = 1024
  max_number_of_levels = 1
  data_type            = 0
  root_node_pointer    = 1024
  free_node_pointer    = -1
  maximum_size         = 2048


-------------------
** node at offset: 1024
** used: 322 bytes
bplustree_node (leaf node):
  left_link      = -1
  right_link     = -1
  overflow_link  = -1
  all_key_count  = 13
  all_key_length = 157

   0. "." (1 bytes) -> 1048576 (16, 0)
   1. ".." (2 bytes) -> 524288 (8, 0)
   2. "Audio" (5 bytes) -> 545627 (8, 21339)
   3. "Bookmarks.zip" (13 bytes) -> 2629612 (40, 8172)
   4. "Number One.zip" (14 bytes) -> 1575864 (24, 3000)
   5. "Number Three.zip" (16 bytes) -> 1575850 (24, 2986)
   6. "Number Two.zip" (14 bytes) -> 1575842 (24, 2978)
   7. "Video" (5 bytes) -> 545655 (8, 21367)
   8. "fpc-2.6.0" (9 bytes) -> 1065193 (16, 16617)
   9. "fpc-2.6.0.i386-haiku.tar" (24 bytes) -> 1587413 (24, 14549)
  10. "fpc-2.6.0.patch" (15 bytes) -> 547336 (8, 23048)
  11. "fpc-2.6.0.source.tar.gz" (23 bytes) -> 546412 (8, 22124)
  12. "fpc-2.6.0.unpack" (16 bytes) -> 547335 (8, 23047)

This is the first undeletable folder "Audio":

/boot> bfsinfo -i . 545627
Copyright (c) 2001-2010 pinc Software.

Inode at block 545627:
-----------------------------------------
inode "Audio":
  magic1             = 3bbe0ad9 (;...) valid
  inode_num          = (8, 21339, 1)(null)
  uid                = 0
  gid                = 0
  mode               =  100040666 (octal)
  flags              = 00040001
  create_time        = Sun Dec  9 14:05:52 2012
  last_modified_time = Fri Dec  7 02:41:00 2012
  parent             = (16, 0, 1)(null)
  attributes         = (0, 0, 0)(null)
  type               = 0
  inode_size         = 2048
  etc                = 00000000
  short_symlink      = -
data_stream:
  direct[00]                = (8, 21340, 1)
  max_direct_range          = 2048
  max_indirect_range        = 0
  max_double_indirect_range = 0
  size                      = 2048
  --
small data section (max. 1816 bytes):
0x43535452 (CSTR), name = "", data = "Audio", 5 bytes
0x52454354 (RECT), name = "_trk/windframe", 16 bytes
0x4c4f4e47 (LONG), name = "_trk/windwkspc", 4 bytes
0x52415754 (RAWT), name = "_trk/columns_le", 185 bytes
0x52415754 (RAWT), name = "_trk/viewstate_le", 57 bytes
0x52415754 (RAWT), name = "_trk/winddecor", 242 bytes
0x4d494d53 (MIMS), name = "BEOS:TYPE", data = "application/x-vnd.Be-directory", 31 bytes
0x43535452 (CSTR), name = "_trk/original_path", data = "/boot/trash/Haiku Stack And Tile/Audio", 39 bytes

This is the first undeletable folder "Video":

/boot> bfsinfo -i . 545655
Copyright (c) 2001-2010 pinc Software.

Inode at block 545655:
-----------------------------------------
inode "Video":
  magic1             = 3bbe0ad9 (;...) valid
  inode_num          = (8, 21367, 1)(null)
  uid                = 0
  gid                = 0
  mode               =  100040666 (octal)
  flags              = 00040001
  create_time        = Sun Dec  9 14:05:53 2012
  last_modified_time = Sun Dec  9 00:28:59 2012
  parent             = (16, 0, 1)(null)
  attributes         = (0, 0, 0)(null)
  type               = 0
  inode_size         = 2048
  etc                = 00000000
  short_symlink      = -
data_stream:
  direct[00]                = (8, 21368, 1)
  max_direct_range          = 2048
  max_indirect_range        = 0
  max_double_indirect_range = 0
  size                      = 2048
  --
small data section (max. 1816 bytes):
0x43535452 (CSTR), name = "", data = "Video", 5 bytes
0x52454354 (RECT), name = "_trk/windframe", 16 bytes
0x4c4f4e47 (LONG), name = "_trk/windwkspc", 4 bytes
0x52415754 (RAWT), name = "_trk/columns_le", 185 bytes
0x52415754 (RAWT), name = "_trk/viewstate_le", 57 bytes
0x52415754 (RAWT), name = "_trk/winddecor", 242 bytes
0x4d494d53 (MIMS), name = "BEOS:TYPE", data = "application/x-vnd.Be-directory", 31 bytes
0x43535452 (CSTR), name = "_trk/original_path", data = "/boot/trash/Haiku Stack And Tile/Video", 39 bytes

[axeld]

Thanks! You did not mention the files actually being directories: can you delete them after a chmod 755 Audio Video? If not, can you repeat the bfsinfo output for those two including the -b flag?

[humdinger]

Replying to axeld:

Thanks! You did not mention the files actually being directories:

Oh, I did too! :)

can you delete them after a chmod 755 Audio Video? If not, can you repeat the bfsinfo output for those two including the -b flag?

What do you know, chmod 755 did the trick... What went wrong?

[Ziusudra]

I've seen this happen when using cp from Terminal to copy folders from a NTFS partition mounted read-only. Though, in that case the files/folders were 444. Didn't test to if mounting writable makes any difference. It might be that they would be 666.

[diver]

I have the same problem in hrev47313. I can delete files after I chmod 755 them. Axel? :)

[axeld]

I just checked the code (and even fixed a related bug), but it is doing the right thing. However, Tracker should try harder here, and try to change the permissions when the deletion failed.

[waddlesplash]

Moving Tracker enhancement tickets out of R1 milestone -- Tracker's source code comes from BeOS R5, so it already has all the features it did on R5.

[humdinger]

Even if Tracker "does the right thing", the result of undeletable files in the Trash can't be explained to users as anything but being a bug. Changing category abck to "bug".