Can't delete some empty and very nested directories.

I can’t delete some very nested and empty directories on an external Hard Disk.

I’ve used the following command on the undeletable folder (this is a sample the problem is present for some more too):

~> sudo rm -Rdf 20180209-194301-109/
rm: cannot remove '20180209-194301-109/backup/home/shared/icons/la-capitaine-mymod/places/16x16': Directory not empty
rm: cannot remove '20180209-194301-109/backup/home/shared/settings/.atom/.apm/async': Directory not empty
rm: cannot remove '20180209-194301-109/backup/home/stefano/.config': Directory not empty

Here are the details:

  • we are talking about a depth of about 15 / 20 directories, and about 150 characters;
  • the external HD is formatted with a NTFS filesystem;
  • this structure is used by a backup program (Back in time), that uses hardlinks to reference the same unmodified file across snapshots (the directory structure pertain to these backups);
  • I’ve checked the HD’s SMART attributes, and there is nothing out of order, no errors or unusual values are reported, so I can (hopefully) rule out hardware issues.
  • I’ve tried to perform a chkdsk from a Windows system to try to fix possible NTFS problems, without solving anything.
  • Also, trying to delete them from Windows gives me no results.

Any clues about this? How can I delete them?

Normally, that should not be a problem. So I’m guessing that this is an NTFS related problem.

I’m not sure whether there are any NTFS experts around.

In Linux go into 20180209-194301-109/backup/home/shared/icons/la-capitaine-mymod/places/16x16 and “ls -la” what’s in there? What’s “rm -rfv” say?

Like xorbe, I would say that when the message says that /xxx/yyy/zzz/ is not empty, the logical first thing to do is to look what is there.

BTW I get the idea that you make your regular backups to an NTFS file system. That does not look as being a good idea to me. No backup of any ownership/permissions, maybe restrictions on file names, etc. But it could of course be that you have your reasons for this and that you have thought about the implications.

Here it is

ls -la
total 0
drwxrwxrwx 1 sbweb users 0 Dec 24  2017 .
drwxrwxrwx 1 sbweb users 0 Mar 10  2018 ..


and

rm -rfv 16x16/
rm: cannot remove '16x16/': Directory not empty


I do believe you, but can you please always post including the prompts? Then we can see e.g. what your working directory is.
It seems you have changed the working directory between those two statements, but we have to guess what you did. Please take into account that we can not look over your shoulder and have to rely on what you show.

Like:

henk@boven:~/test/leeg> ls -la
totaal 8
drwxr-xr-x  2 henk wij 4096 19 okt 11:02 .
drwxr-xr-x 24 henk wij 4096 19 okt 11:02 ..
henk@boven:~/test/leeg>

I repeat my concern about you using a non-Linux file system as if it is a full fledged Linux file system.

You talk about hard links. I do not even know if that is supported on an NTFS file system.

IMHO one should only use non-Linux file systems to exchange files with non-Linux systems. Not as if it is one of the Linux file systems.

It’s likely that the NTFS filesystem is in an inconsistent state, and this may need a Windows environment to restore it. However, you may get lucky with using the ‘ntfsfix’ utility. For example, if the external device is sdb1…

sudo ntfsfix -b -d /dev/sdb1

YMMV.

I’m sorry, I was in a hurry, here are the full info as you requested

sbweb@opensuse-kde:/run/media/sbweb/MyPassport/Backup/backintime/linux/stefano/Home/20180209-194301-109/backu
p/home/shared/icons/la-capitaine-mymod/places/16x16> LANG=C ls -la                
total 0
drwxrwxrwx 1 sbweb users 0 Dec 24  2017 .
drwxrwxrwx 1 sbweb users 0 Mar 10  2018 ..



and

sbweb@opensuse-kde:/run/media/sbweb/MyPassport/Backup/backintime/linux/stefano/Home/20180209-194301-109/backu
p/home/shared/icons/la-capitaine-mymod/places> LANG=C rm -rfv 16x16/
rm: cannot remove '16x16/': Directory not empty


About using a NTFS, I use that HD for a Windows machine backups too. I understand what you say and I’m switching to a different backup solution that uses compressed archives instead of plain files (that’s why I’m in need of deleting these), but the fact is that this problems arised and now I’m trying to solve it.


Also

sbweb@opensuse-kde:~> sudo ntfsfix -bd /dev/sdb1  
Mounting volume... OK
Processing of $MFT and $MFTMirr completed successfully.
Checking the alternate boot sector... OK
NTFS volume version is 3.1.
Going to un-mark the bad clusters ($BadClus)... No bad clusters...OK
NTFS partition /dev/sdb1 was processed successfully.


Maybe others come with better advice/hint (I really do not know much about anything MS Windows), but you could check how the file system is mounted:

mount | grep media

On 10/19/18 6:46 AM, sekhemty wrote:
>
> hcvv;2883806 Wrote:
>> I do believe you, but can you please always post including the prompts?
>> Then we can see e.g. what your working directory is.
>> It seems you have changed the working directory between those two
>> statements, but we have to guess what you did. Please take into account
>> that we can not look over your shoulder and have to rely on what you
>> show.
>>
>> Like:
>>>
> Code:
> --------------------
> > > henk@boven:~/test/leeg> ls -la
> > totaal 8
> > drwxr-xr-x 2 henk wij 4096 19 okt 11:02 .
> > drwxr-xr-x 24 henk wij 4096 19 okt 11:02 …
> > henk@boven:~/test/leeg>
> --------------------
>>>
>
> I’m sorry, I was in a hurry, here are the full info as you requested
>
>
>
> Code:
> --------------------
> sbweb@opensuse-kde:/run/media/sbweb/MyPassport/Backup/backintime/linux/stefano/Home/20180209-194301-109/backu
> p/home/shared/icons/la-capitaine-mymod/places/16x16> LANG=C ls -la
> total 0
> drwxrwxrwx 1 sbweb users 0 Dec 24 2017 .
> drwxrwxrwx 1 sbweb users 0 Mar 10 2018 …
>

Try using ‘rm -iR’. this will require you to confirm the deletion of
every file/dir and often, for me, present a file/dir that is otherwise
not shown.


Ken
unix since 1986
S.u.S.E.-openSUSE since 1998

Use a format/container that preserves ownership like TAR. Copying direct to a Windows format loses permission bits

Some questions…

What applications wrote to those nested directories,
Specifically if these are backup archives then are all written by Linux apps or a mixture of Linux and Windows backup apps?
If any were written by Windows backup apps, were any by the Windows Backup app (ie WinPro or WinEnt), or a third party app?

How specifically are you mounting this target location, direct attached media or by way of a network share(If a network share then you may have to deal with share permissions, not just file permissions, and this includes mapping a network share)?

An outside possibility,
I’ve only relatively recently found that Microsoft has been adding additional security bits that only it knows about and is not sharing with the public, likely as a way to protect certain parts of the file system from hackers. I’m still determining all the target locations Microsoft want to protect in this way so wouldn’t know if this might affect you.

In any case,
If you want to start exploring exactly which subdirectories can’t be deleted, you can drop down one level from the parent directory and try the same command on the child directories… then drop down another level and repeat.

TSU

This situation is where OFMs shine. e.g. in mc you navigate into the directory that is “not empty” to see why it is “not empty”, select whatever it contains, and use the F8 key to eradicate it. Likewise, on the parent directory you can use F8, and because it is not empty it will ask if you wish to delete all its contents, you confirm, and even though the contents are weirdly named or “hidden”, they disappear.

Exactly. Seen the issue, and the the ‘rm -iR’ resultst differing from ‘ls’ results, and found this worked.
But, it could very well be the result of an unclean ntfs.

… which is what I also suspect. Boot from Windows and run chkdsk (or whatever they use, now).

I also think this is the case, as I mentioned in my previous reply. Some inconsistencies can be corrected by ntfsfix while others need the native windows utility to correct.

I had to run chkdsk multiple times, but it solved my problem.

Thank you all for your support.

Thanks for the update. Good to read that the filesystem is now consistent again.