opensuse v12,1
linux 3.1.0-1.2-desktop x86_64

  This has become "the file that cannot be deleted."

$ ls -l
ls: cannot access versi�: No such file or directory
total 0
-????????? ? ? ? ?            ? versi?
$ stat ver*
stat: cannot stat `versi\377': No such file or directory
$  rm ver*
rm: cannot remove `versi\377': No such file or directory

  So far nothing I have tried has removed the file. It can be listed,
but that is about it. Every other tool I tried says it does not exist.
- rm versi�
- getting the inode directly (ls -il)
- various methods of writing the filename (quotes, escape chars, ...)
  The only suggestion I have received that would work is: backup the
disk, format it, restore it. Seems a bit extreme.

  Any suggestions?

-- 
James Moe
jmm-list at sohnen-moe dot com

James Moe wrote:
> opensuse v12,1
> linux 3.1.0-1.2-desktop x86_64
> 
>   This has become "the file that cannot be deleted."
> 
> $ ls -l
> ls: cannot access versi�: No such file or directory
> total 0
> -????????? ? ? ? ?            ? versi?
> $ stat ver*
> stat: cannot stat `versi\377': No such file or directory
> $  rm ver*
> rm: cannot remove `versi\377': No such file or directory
> 
>   So far nothing I have tried has removed the file. It can be listed,
> but that is about it. Every other tool I tried says it does not exist.
> - rm versi�
> - getting the inode directly (ls -il)
> - various methods of writing the filename (quotes, escape chars, ...)
>   The only suggestion I have received that would work is: backup the
> disk, format it, restore it. Seems a bit extreme.
> 
>   Any suggestions?
> 

cp -r the directory to /tmp/directory.

rm -r the entire directory
mv it back?

If that works its gone, if not then mv and cp can 'see' it.

then its just a matter of finding the right wildcard.

ISTR this used to be done as a joke..there were things like backspaces 
in the file name..try ls | hd if your system has it.

A bit extreme, but not as much as wiping the disk: did you try to write a little C program that calls unlink()?

BTW, I notice now the result of your ls.  It seems like something wrong with the filesystem, not only the file.

On 24/01/12 11:02, James Moe wrote:
> opensuse v12,1
> linux 3.1.0-1.2-desktop x86_64
>
>    This has become "the file that cannot be deleted."
>
> $ ls -l
> ls: cannot access versi�: No such file or directory
> total 0
> -????????? ? ? ? ?            ? versi?
> $ stat ver*
> stat: cannot stat `versi\377': No such file or directory
> $  rm ver*
> rm: cannot remove `versi\377': No such file or directory
>
>    So far nothing I have tried has removed the file. It can be listed,
> but that is about it. Every other tool I tried says it does not exist.
> - rm versi�
> - getting the inode directly (ls -il)
> - various methods of writing the filename (quotes, escape chars, ...)
>    The only suggestion I have received that would work is: backup the
> disk, format it, restore it. Seems a bit extreme.
>
>    Any suggestions?

Try to find the exact name of the file: ls -lab | pg
After that it's safer to rename the file instead of ls-ing it or 
rm-ing with shell doing expandoes on weird characters.

However, it may be that inode numbers are pointing to unallocated 
inodes, so first try to umount that partition and do as root fsck -f 
/dev/your-partition-with-weird-file. It may fix the problem.

James Moe <jimoeDESPAM@sohnen-moe.com> wrote:
> opensuse v12,1
> linux 3.1.0-1.2-desktop x86_64
> 
>   This has become "the file that cannot be deleted."
> 
> $ ls -l
> ls: cannot access versi?: No such file or directory
> total 0
> -????????? ? ? ? ?            ? versi?
> $ stat ver*
> stat: cannot stat `versi\377': No such file or directory
> $  rm ver*
> rm: cannot remove `versi\377': No such file or directory
> 
>   So far nothing I have tried has removed the file. It can be listed,
> but that is about it. Every other tool I tried says it does not exist.
> - rm versi?
> - getting the inode directly (ls -il)
> - various methods of writing the filename (quotes, escape chars, ...)
>   The only suggestion I have received that would work is: backup the
> disk, format it, restore it. Seems a bit extreme.
> 
>   Any suggestions?
> 

You can always do:
rm -i *
and keep saying no until that file comes up.

Or, you can do:
rm \- and then hit tab to complete the file name.

Feranija <feranija@mouse-potato.com> writes:
> James Moe wrote:

>> opensuse v12,1
>> linux 3.1.0-1.2-desktop x86_64
>>
>>    This has become "the file that cannot be deleted."
>>
>> $ ls -l
>> ls: cannot access versi�: No such file or directory
>> total 0
>> -????????? ? ? ? ?            ? versi?
>> $ stat ver*
>> stat: cannot stat `versi\377': No such file or directory
>> $  rm ver*
>> rm: cannot remove `versi\377': No such file or directory
>>
>>    So far nothing I have tried has removed the file. It can be listed,
>> but that is about it. Every other tool I tried says it does not exist.
>> - rm versi�
>> - getting the inode directly (ls -il)
>> - various methods of writing the filename (quotes, escape chars, ...)
>>    The only suggestion I have received that would work is: backup the
>> disk, format it, restore it. Seems a bit extreme.
>>
>>    Any suggestions?
>
> Try to find the exact name of the file: ls -lab | pg
> After that it's safer to rename the file instead of ls-ing it or
> rm-ing with shell doing expandoes on weird characters.

ls can't stat it, despite having just got the name from readdir().
Attempting to spell the name in other ways is not going to help.
There's no file here, just a name; the directory entry has been mangled.

> However, it may be that inode numbers are pointing to unallocated
> inodes, so first try to umount that partition and do as root fsck -f 
> /dev/your-partition-with-weird-file. It may fix the problem.

I think this is the right answer.

-- 
http://www.greenend.org.uk/rjk/

James Moe wrote:
> opensuse v12,1
> linux 3.1.0-1.2-desktop x86_64
> 
>   This has become "the file that cannot be deleted."
> 
> $ ls -l
> ls: cannot access versi�: No such file or directory
> total 0
> -????????? ? ? ? ?            ? versi?
> $ stat ver*
> stat: cannot stat `versi\377': No such file or directory
> $  rm ver*
> rm: cannot remove `versi\377': No such file or directory
> 
>   So far nothing I have tried has removed the file. It can be listed,
> but that is about it. Every other tool I tried says it does not exist.
> - rm versi�
> - getting the inode directly (ls -il)

You haven't said why using the inode doesn't work, but knowing the inode
number, the following should work.

    find . -maxdepth 1 -inum 123456 -delete

where you would replace 123456 by the inode number listed by ls.

-- 
Gary Johnson

On 2012-01-24, James Moe <jimoeDESPAM@sohnen-moe.com> wrote:
> opensuse v12,1
> linux 3.1.0-1.2-desktop x86_64
>
>   This has become "the file that cannot be deleted."
>
> $ ls -l
> ls: cannot access versi???: No such file or directory
> total 0
> -????????? ? ? ? ?            ? versi?
> $ stat ver*
> stat: cannot stat `versi\377': No such file or directory
> $  rm ver*
> rm: cannot remove `versi\377': No such file or directory
>
>   So far nothing I have tried has removed the file. It can be listed,
> but that is about it. Every other tool I tried says it does not exist.
> - rm versi???
> - getting the inode directly (ls -il)
> - various methods of writing the filename (quotes, escape chars, ...)
>   The only suggestion I have received that would work is: backup the
> disk, format it, restore it. Seems a bit extreme.
>
>   Any suggestions?
>

fsck

What directory is it in?
ls v*>/tmp/l
hexedit /tmp/l
to find out exactly what characters are in the file name.

James Moe <jimoeDESPAM@sohnen-moe.com> writes:

> opensuse v12,1
> linux 3.1.0-1.2-desktop x86_64
>
>   This has become "the file that cannot be deleted."
>
> $ ls -l
> ls: cannot access versi�: No such file or directory
> total 0
> -????????? ? ? ? ?            ? versi?
> $ stat ver*
> stat: cannot stat `versi\377': No such file or directory
> $  rm ver*
> rm: cannot remove `versi\377': No such file or directory
>
>   So far nothing I have tried has removed the file. It can be listed,
> but that is about it. Every other tool I tried says it does not exist.
> - rm versi�
> - getting the inode directly (ls -il)
> - various methods of writing the filename (quotes, escape chars, ...)
>   The only suggestion I have received that would work is: backup the
> disk, format it, restore it. Seems a bit extreme.
>
>   Any suggestions?

Last time I saw a bunch of question marks in the output of ls,
the disk was failing due to excessive heat in the room.

Look for errors in /var/log/messages and check to see if the
file system is mounted "ro" due to errors.


-- 
Dan Espen

This is a MIME GnuPG-signed message.  If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
To open this message correctly you will need to install E-mail or Usenet
software that supports modern Internet standards.

--=_mimegpg-monster.email-scan.com-29700-1327446344-0001
Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

James Moe writes:

> opensuse v12,1
> linux 3.1.0-1.2-desktop x86_64
>
>   This has become "the file that cannot be deleted."
>
> $ ls -l
> ls: cannot access versi=EF=BF=BD: No such file or directory
> total 0
> -????????? ? ? ? ?            ? versi?

>   Any suggestions?

You need to fsck the partition, to fix this.

If you know what that means, then do it.

If not, I'm not familiar with opensuse's initscripts, but there should be =
a =20
way for you indicate that all filesystems should be fscked at the next =20
reboot. It's usually an extra kernel boot argument (manually added at the =20
boot prompt), or some dummy file. For Fedora creating /.forcefsck trigger=
s a =20
fsck at the next reboot.



--=_mimegpg-monster.email-scan.com-29700-1327446344-0001
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk8fOUgACgkQx9p3GYHlUOJjAACeP1dAmxjMdllVYCuG9Wj4FQ65
m20AnjTPiWrxAzj4EQi/NXfGFAAHIi4y
=q1l/
-----END PGP SIGNATURE-----

--=_mimegpg-monster.email-scan.com-29700-1327446344-0001--

On 01/24/2012 12:28 PM, The Natural Philosopher wrote:
> cp -r
$ cp -r LabyrinthIndex/ tmp/
cp: cannot stat `LabyrinthIndex/versi\377': No such file or directory

-- 
James Moe
jmm-list at sohnen-moe dot com

On 01/24/2012 12:38 PM, Feranija wrote:
> 
> Try to find the exact name of the file: ls -lab | pg
> After that it's safer to rename the file instead of ls-ing it or rm-ing
> with shell doing expandoes on weird characters.
> 
$ ls -lab
ls: cannot access versi\377: No such file or directory
total 8
drwxr-xr-x 2 jmoe users 4096 Jan 18 11:39 ./
drwx------ 4 jmoe users 4096 Jan 19 14:58 ../
-????????? ? ?    ?        ?            ? versi\377

> However, it may be that inode numbers are pointing to unallocated
> inodes, so first try to umount that partition and do as root fsck -f
> /dev/your-partition-with-weird-file. It may fix the problem.

  I did boot to a rescue disk and ran fsck on all of the volumes. They
all reported clean.

-- 
James Moe
jmm-list at sohnen-moe dot com

On 01/24/2012 01:02 PM, root wrote:
> You can always do:
> rm -i *
>
$ rm -i *
rm: cannot remove `versi\377': No such file or directory
> 
> Or, you can do:
> rm \- and then hit tab to complete the file name.
>
$ rm \- versi�
rm: cannot remove `-': No such file or directory
rm: cannot remove `versi\377': No such file or directory


-- 
James Moe
jmm-list at sohnen-moe dot com

On 01/24/2012 01:23 PM, Gary Johnson wrote:
> 
> You haven't said why using the inode doesn't work, but knowing the inode
> number, the following should work.
> 
$ ls -il
ls: cannot access versi�: No such file or directory
total 0
? -????????? ? ? ? ?            ? versi?

-- 
James Moe
jmm-list at sohnen-moe dot com

On 01/24/2012 01:31 PM, unruh wrote:
> ls v*>/tmp/l
>
$ ls v*>/tmp/l
ls: cannot access versi�: No such file or directory

-- 
James Moe
jmm-list at sohnen-moe dot com

On 01/24/2012 02:49 PM, Dan Espen wrote:
> 
> Last time I saw a bunch of question marks in the output of ls,
> the disk was failing due to excessive heat in the room.
> 
  It is winter time here. The room temperature does not exceed 72 F.
Even the CPU temp is less than 100 F.

> Look for errors in /var/log/messages and check to see if the
> file system is mounted "ro" due to errors.
> 
  The disk is less than a year old.
  There are no errors in the message log.

/dev/sdd1 on /home type ext4
(rw,relatime,user_xattr,acl,barrier=1,data=ordered)

-- 
James Moe
jmm-list at sohnen-moe dot com

On 01/24/2012 04:05 PM, Sam wrote:
> 
> You need to fsck the partition, to fix this.
> 
  Did that already. All volumes are clean.
  Unless there are special options to use?
"fsck /dev/sdd1" returned CLEAN.

-- 
James Moe
jmm-list at sohnen-moe dot com

On 01/24/2012 05:22 PM, James Moe wrote:
> On 01/24/2012 12:38 PM, Feranija wrote:
>>
>> Try to find the exact name of the file: ls -lab | pg
>> After that it's safer to rename the file instead of ls-ing it or rm-ing
>> with shell doing expandoes on weird characters.
>>
> $ ls -lab
> ls: cannot access versi\377: No such file or directory
> total 8
> drwxr-xr-x 2 jmoe users 4096 Jan 18 11:39 ./
> drwx------ 4 jmoe users 4096 Jan 19 14:58 ../
> -????????? ? ?    ?        ?            ? versi\377
>
>> However, it may be that inode numbers are pointing to unallocated
>> inodes, so first try to umount that partition and do as root fsck -f
>> /dev/your-partition-with-weird-file. It may fix the problem.
>
>    I did boot to a rescue disk and ran fsck on all of the volumes. They
> all reported clean.

Did you use the "-f" option to force the fsck on what is an apparently
clean volume?  If so, and fsck still did not find any problem, then
here's what you need to do:

    Run "ls -i" to find the inode number for the bad inode.

    Run "debugfs -w /dev/sdd1

    At the "debugfs:" prompt, type "stat <nnnnn>", where nnnnn is
    the inode number you found above.  (The angle brackets are part
    of the syntax.)  Verify that this inode does indeed contain
    nonsense.

    Type "clri <nnnnn>" to clear the inode.  Then "quit".

    Run "fsck -f /dev/sdd1" again.  This time it _will_ find and
    correct some errors.

-- 
Bob Nichols         AT comcast.net I am "RNichols42"

This is a MIME GnuPG-signed message.  If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
To open this message correctly you will need to install E-mail or Usenet
software that supports modern Internet standards.

--=_mimegpg-monster.email-scan.com-23735-1327451091-0001
Content-Type: text/plain; format=flowed; delsp=yes; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

James Moe writes:

> On 01/24/2012 04:05 PM, Sam wrote:
> >
> > You need to fsck the partition, to fix this.
> >
>   Did that already. All volumes are clean.
>   Unless there are special options to use?
> "fsck /dev/sdd1" returned CLEAN.

Are you sure that you have the right partition. Furthermore, it has to be  
explicitly unmounted. fsck won't touch a mounted partition.


--=_mimegpg-monster.email-scan.com-23735-1327451091-0001
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk8fS9MACgkQx9p3GYHlUOIXogCdHfo9FflQplXLb2dHCpY88mkC
ByEAnRjK4poDVg/0ESPcU0l6OoAk3BFL
=NNkB
-----END PGP SIGNATURE-----

--=_mimegpg-monster.email-scan.com-23735-1327451091-0001--

On 2012-01-24, James Moe <jimoeDESPAM@sohnen-moe.com> wrote:
> On 01/24/2012 02:49 PM, Dan Espen wrote:
>> 
>> Last time I saw a bunch of question marks in the output of ls,
>> the disk was failing due to excessive heat in the room.
>> 
>   It is winter time here. The room temperature does not exceed 72 F.
> Even the CPU temp is less than 100 F.
>
>> Look for errors in /var/log/messages and check to see if the
>> file system is mounted "ro" due to errors.
>> 
>   The disk is less than a year old.
>   There are no errors in the message log.

The age of the disk is irrelevant. Disks can fail at any time. 

>
> /dev/sdd1 on /home type ext4
> (rw,relatime,user_xattr,acl,barrier=1,data=ordered)
>

James Moe <jimoeDESPAM@sohnen-moe.com> wrote:
> On 01/24/2012 01:02 PM, root wrote:
>> You can always do:
>> rm -i *
>>
> $ rm -i *
> rm: cannot remove `versi\377': No such file or directory
>> 
>> Or, you can do:
>> rm \- and then hit tab to complete the file name.
>>
> $ rm \- versi?
> rm: cannot remove `-': No such file or directory
> rm: cannot remove `versi\377': No such file or directory
> 

Yes, that was bullshit. Hard to believe but I came
up with almost the same problem since I posted the
above. In my case I needed to rename the file
whose name was something like this:

-_Junkstuff_-morejunkstuff

What worked for me was:

mv .\-    then hit tab to complete name followed by the new name.

This was tested in contrast to my earlier crap.


The rm -i *
has always worked for me if I just want to remove a file.

Sorry for my previous error.
> 

On Tue, 24 Jan 2012 12:02:41 -0700, James Moe wrote:
> $ ls -l
> ls: cannot access versi�: No such file or directory total 0
> -????????? ? ? ? ?            ? versi? $ stat ver*

[deletia]

>   Any suggestions?

Interesting suggestions so far, all wrong...

First some background:  Somewhere in the evolution of gvfs it created a 
filename of ".gvfs" in a user's home directory that appeared the same as 
your file "versi?".  (Maybe it was a subdirectory, can't remember now)  I 
"assume" this file was somehow needed/used by gvfs, but never persued 
it.  Now, at least as of gvfs-1.6.2-1.fc13.i686 (Fedora 13), gvfs creates 
a subdirectory in the users home directory called ".gvfs" that looks 
"normal", i.e., with access control of "dr-x------.".  Much better 
behavior.

I no longer have an installation that has the older version of gvfs that 
creates a similar file, so I can't mess around with it.  But I can 
definitively state that THERE IS NOTHING WRONG WITH YOUR FILESYSTEM!  
Running fsck won't hurt anything but won't "fix" this, since it isn't 
broken.

Is this software, "versi", open source? If so investigate the source code 
to see what that file is used for and how it is created.  Might be 
useful...

James Moe <jimoeDESPAM@sohnen-moe.com> writes:

R> On 01/24/2012 02:49 PM, Dan Espen wrote:
>> 
>> Last time I saw a bunch of question marks in the output of ls,
>> the disk was failing due to excessive heat in the room.
>> 
>   It is winter time here. The room temperature does not exceed 72 F.
> Even the CPU temp is less than 100 F.
>
>> Look for errors in /var/log/messages and check to see if the
>> file system is mounted "ro" due to errors.
>> 
>   The disk is less than a year old.
>   There are no errors in the message log.
>
> /dev/sdd1 on /home type ext4
> (rw,relatime,user_xattr,acl,barrier=1,data=ordered)

Looks okay to me.
Guess that's not it.

-- 
Dan Espen

James Moe wrote:
> On 01/24/2012 01:23 PM, Gary Johnson wrote:
> > 
> > You haven't said why using the inode doesn't work, but knowing the inode
> > number, the following should work.
> > 
> $ ls -il
> ls: cannot access versi�: No such file or directory
> total 0
> ? -????????? ? ? ? ?            ? versi?

I see.  Sorry.

-- 
Gary Johnson

On 2012-01-24, James Moe <jimoeDESPAM@sohnen-moe.com> wrote:
> On 01/24/2012 04:05 PM, Sam wrote:
>> 
>> You need to fsck the partition, to fix this.
>> 
>   Did that already. All volumes are clean.
>   Unless there are special options to use?
> "fsck /dev/sdd1" returned CLEAN.

As another poster suggested, try the -f option.  Without -f, fsck
_ASSUMES_ it's clean if the metadata says so.  With -f, fsck will
do to the work to _KNOW_ whether it's clean.

-- 
Robert Riches
spamtrap42@jacob21819.net
(Yes, that is one of my email addresses.)

On 01/24/2012 05:56 PM, root wrote:
> mv .\-    then hit tab to complete name followed by the new name.
>
mv .\- versi� ../tmp/
mv: cannot stat `.-': No such file or directory
mv: cannot stat `versi\377': No such file or directory


-- 
James Moe
jmm-list at sohnen-moe dot com

James Moe wrote:
> On 01/24/2012 12:28 PM, The Natural Philosopher wrote:
>> cp -r
> $ cp -r LabyrinthIndex/ tmp/
> cp: cannot stat `LabyrinthIndex/versi\377': No such file or directory
> 

right then copy and delete origonal;

But as others have been saying the disk is f*cked

And therefore needs to be fscked.

On 2012-01-25, The Natural Philosopher <tnp@invalid.invalid> wrote:
> James Moe wrote:
>> On 01/24/2012 12:28 PM, The Natural Philosopher wrote:
>>> cp -r
>> $ cp -r LabyrinthIndex/ tmp/
>> cp: cannot stat `LabyrinthIndex/versi\377': No such file or directory
>> 
>
> right then copy and delete origonal;

He almost certainly cannot delete the original, since he has tried. 
Now, rm -r <directory> might work, but also might not.

>
> But as others have been saying the disk is f*cked

Again, unclear 
>
> And therefore needs to be fscked.

It apparently was, a few times. He reported no errors found and no file
change. 

On 2012-01-24, James Moe <jimoeDESPAM@sohnen-moe.com> wrote:
>   This has become "the file that cannot be deleted."
>   ...
>   So far nothing I have tried has removed the file....

Can your file manager of choice delete it?  Can Midnight Commander
delete it?
-- 
                                 Chick Tower

For e-mail:  aols2 DOT sent DOT towerboy AT xoxy DOT net

On 2012-01-24, James Moe <jimoeDESPAM@sohnen-moe.com> wrote:
> On 01/24/2012 01:31 PM, unruh wrote:
>> ls v*>/tmp/l
>>
> $ ls v*>/tmp/l
> ls: cannot access versi�: No such file or directory
>
Try 'ls -d v* >/tmp/l'. Maybe the system thinks it's something like a 
directory or a symbolic link.



-- 
Why is it that people believe someone who says the world will end in 2012,
but when they see a "wet paint" sign they have to touch it for themselves?

James Moe <jimoeDESPAM@sohnen-moe.com> writes:
> Dan Espen wrote:

>> Look for errors in /var/log/messages and check to see if the
>> file system is mounted "ro" due to errors.
>> 
>   The disk is less than a year old.
>   There are no errors in the message log.

Try dmesg.  Any diagnostics will be in the kernel log output, which may
not turn up in /var/log/messages, depending on the system's logging
configuration.


None of the guesswork people are posting about ls has any chance of
working.  User processes cannot stat this name, and randomly trying
different options, globbing and I/O redirection is not going to make the
slightest bit of difference to this fact.  The name has no connection to
an underlying inode.

The mangling of the name itself is a red herring, though quite possibly
shares an underlying cause.

The people telling you how to make sure fsck actually checks the
relevant filesystem, rather than skipping it because it's marked as
clean, are the ones to pay attention to.

-- 
http://www.greenend.org.uk/rjk/

On 01/26/2012 12:47 AM, Bill Marcum wrote:
> ls -d v* >/tmp/l

$ ls -d v* >../tmp/l
ls: cannot access versi�: No such file or directory


-- 
James Moe
jmm-list at sohnen-moe dot com

On 01/25/2012 08:41 PM, Chick Tower wrote:
> On 2012-01-24, James Moe <jimoeDESPAM@sohnen-moe.com> wrote:
>>   This has become "the file that cannot be deleted."
>>   ...
>>   So far nothing I have tried has removed the file....
> 
> Can your file manager of choice delete it?  Can Midnight Commander
> delete it?

  No. No.

-- 
James Moe
jmm-list at sohnen-moe dot com

At Thu, 26 Jan 2012 08:59:34 -0700 James Moe <jimoeDESPAM@sohnen-moe.com> wrote:

> 
> On 01/25/2012 08:41 PM, Chick Tower wrote:
> > On 2012-01-24, James Moe <jimoeDESPAM@sohnen-moe.com> wrote:
> >>   This has become "the file that cannot be deleted."
> >>   ...
> >>   So far nothing I have tried has removed the file....
> > 
> > Can your file manager of choice delete it?  Can Midnight Commander
> > delete it?
> 
>   No. No.
> 

It is pretty clear that the file system is broken on some level. At the
very least, you have a corrupted directory file (it has a dirent that
does not point to a proper inode). You probably really need to
*forcibly* (as in -f) fsck it.  If you *cleanly* un mount a file system
and then try to fsck it, nothing will happen, even if the file system
is totally borked, since umount will mark the file system as 'clean'. 
Fsck will see the clean bit and do nothing, unless the file system is
past its mount count or has gone too many days without being checked. 
Using the -f option to fsck will cause fsck to ignore the clean bit and
check the file system.  The -f bit will thus *force* a fsck of an
*apparently* clean file system.


-- 
Robert Heller             -- 978-544-6933 / heller@deepsoft.com
Deepwoods Software        -- http://www.deepsoft.com/
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments


                                                                                                                              

On 2012-01-25, root <NoEMail@home.org> wrote:
>
> What worked for me was:
>
> mv .\-    then hit tab to complete name followed by the new name.
>
> This was tested in contrast to my earlier crap.
>
I think you meant ./-  and that wouldn't help the original poster in this
thread, since the problem isn't a filename beginning with '-'.


-- 
Why is it that people believe someone who says the world will end in 2012,
but when they see a "wet paint" sign they have to touch it for themselves?

On 01/24/2012 12:02 PM, James Moe wrote:
> 
>   This has become "the file that cannot be deleted."
> 
> $ ls -l
> ls: cannot access versi�: No such file or directory
> total 0
> -????????? ? ? ? ?            ? versi?

  I finally booted to a rescue disk and ran fsck with the "-f" option on
the volume in question. It fixed 3 fs errors: a broken inode value, a
missing directory entry, and a filename with an illegal character.
  After restarting the main system, the file could be deleted.

$ ll
total 4
-rw-r--r-- 1 jmoe users 5 Jun 10  2010 versi?.
$ rm versi?
$

-- 
James Moe
jmm-list at sohnen-moe dot com

James Moe wrote:
> On 01/24/2012 12:02 PM, James Moe wrote:
>>   This has become "the file that cannot be deleted."
>>
>> $ ls -l
>> ls: cannot access versi�: No such file or directory
>> total 0
>> -????????? ? ? ? ?            ? versi?
> 
>   I finally booted to a rescue disk and ran fsck with the "-f" option on
> the volume in question. It fixed 3 fs errors: a broken inode value, a
> missing directory entry, and a filename with an illegal character.
>   After restarting the main system, the file could be deleted.
> 

Top marks to el Kettlewell

> $ ll
> total 4
> -rw-r--r-- 1 jmoe users 5 Jun 10  2010 versi?.
> $ rm versi?
> $
> 

On 2012-01-27, The Natural Philosopher <tnp@invalid.invalid> wrote:
>
> Top marks to el Kettlewell

....and the others who also suggested fsck -f.  :)

--keith

-- 
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

On 01/27/2012 08:18 PM, The Natural Philosopher wrote:
> Top marks to el Kettlewell

or 'Jim' in the openSUSE.org forum who gave the correct answer nine days 
ago..

-- 
DenverD