l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
October 20: Web Application Hacking: How to Make and Break Security on the Web
Next Installfest:
Latest News:
Oct. 10: LUGOD Installfests coming again soon
Page last updated:
2004 May 21 14:31

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Removing Files
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Removing Files

Ken Herron wrote:

--On Friday, May 21, 2004 11:48:16 +0000 Tim Riley <timriley@timriley.net> wrote:

> r = 114
> ´ = 4294967220

This character is suspicious. It's supposed to be 39, so
apparently there are colors or other attribute information

The actual character code is 180 decimal, which is an acute accent in the latin1 (or ISO8859-1) character set. You're getting 4294967220 because of a bug in the program. ptr points to signed characters so 180 is interpreted as -76; when *ptr is passed to printf(), the value is sign-extended to a signed int and then printed as if it were unsigned.
When the bug was fixed, changing %u to %d, I recieve the same output of -76 for the character.

But none of this really matters. When you get a filename from readdir(), you should be able to call unlink() on that string and refer to the same file. Funny high-bit characters in the string shouldn't be an issue at this level. Certainly running "rm -r" on the directory containing the file should have worked.

Daniel, the test program you posted actually copies the filename string into another buffer usint sprintf(). I don't think *printf() is supposed to do character-set conversions, but maybe it does. Try using strcat() to construct the pathname for deletion, or else just chdir() into the directory containing the file and call unlink() on the contents of the d_name buffer.

I tried replacing the sprintf command with string commands in the original program and that did not work. The involved calling the exact path the to the file with unlink and did not work.

Here is the program output:
# ./test_rev2.e
Evil Dead 3 - Army of Darkness (Director´s Cut).avi
Found the File!
Full Filename:
/usr/media/movies/Evil Dead 3 - Army of Darkness (Director´s Cut).avi
Could not delete file
Error: No such file or directory

Next I tried to use your suggestion of chdir() and unlink the the file that way with having to build the filename to make sure that was not causing a problem. This did not work as well:

# ./delete_file.e
Evil Dead 3 - Army of Darkness (Director´s Cut).avi
Found the File!
Could not delete file
Error: No such file or directory

I then tried to delete the directory itself using several commands ( unlink(), rmdir(), remove() ). All these commands failed informing me that what I was trying to delete was a directory. And I thanked them for that information which was already known ;-). Here is the program output:

# ./directory_remove.e

Try to unlink the directory
Could not delete file
Error: Is a directory

Try to rmdir the directory
Could not delete file
Error: Is a directory

Try to remove the directory
Could not delete file
Error: Is a directory

The source code for the programs can be found here:

*** These programs will delete files without prompting so be careful.

If this doesn't work, then it seems to me you have filesystem corruption, despite the fact that fsck didn't find anything to fix. You might have to resort to something drastic like:

1) Become root.
2) Unlink the directory containing the file (see rm's "-d" or "--directory" option).
3) Unmount the filesystem and fsck it.

I must be doing something wrong, because I could not get "rm -d" to work even on a normal directory. It kept informing me that it was a directory that I was trying to delete. Here is the sequence of commands if you are curious:

# umount /usr/media/
# !fs
fsck.jfs -v -f /dev/vg/media
fsck.jfs version 1.1.3, 05-Sep-2003
processing started: 5/21/2004 13.19.5
The current device is: /dev/vg/media
Open(...READ/WRITE EXCLUSIVE...) returned rc = 0
Primary superblock is valid.
The type of file system for the device is JFS.
Block size in bytes: 4096
Filesystem size in blocks: 78643200
**Phase 0 - Replay Journal Log
LOGREDO: Log already redone!
logredo returned rc = 0
**Phase 1 - Check Blocks, Files/Directories, and Directory Entries
**Phase 2 - Count links
**Phase 3 - Duplicate Block Rescan and Directory Connectedness
**Phase 4 - Report Problems
**Phase 5 - Check Connectivity
**Phase 6 - Perform Approved Corrections
**Phase 7 - Rebuild File/Directory Allocation Maps
**Phase 8 - Rebuild Disk Allocation Maps
Filesystem Summary:
Blocks in use for inodes: 1560
Inode count: 12480
File count: 8052
Directory count: 406
Block count: 78643200
Free block count: 21469177
314572800 kilobytes total disk space.
5775 kilobytes in 406 directories.
228607070 kilobytes in 8052 user files.
0 kilobytes in extended attributes
0 kilobytes in access control lists
94797 kilobytes reserved for system use.
85876708 kilobytes are available for use.
Filesystem is clean.
All observed inconsistencies have been repaired.
Filesystem has been marked clean.
**** Filesystem was modified. ****
processing terminated: 5/21/2004 13:19:24 with return code: 0 exit code: 0.
# mount /usr/media/
# cd /usr/media/
# rm -d /usr/media/movies/
rm: cannot remove `/usr/media/movies/': Is a directory
# rm -df /usr/media/movies/
rm: cannot remove `/usr/media/movies/': Is a directory
# rm --directory --force --interactive --verbose /usr/media/movies
rm: cannot remove directory `/usr/media/movies': Is a directory

Sorry for all the trouble, but I am thinking just to move all the files off this partition and then reformat the partition to be done with it and then not copy those files to this partition again :-)


vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
O'Reilly and Associates
For numerous book donations.