Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 5 May 2013 04:34:32 +0200
From:      Polytropon <freebsd@edvax.de>
To:        Michael Bird <michael_bird@yahoo.com>
Cc:        "freebsd-questions@freebsd.org" <freebsd-questions@freebsd.org>
Subject:   Re: ls(1), rm(1) - No such file or directory even though they are there.
Message-ID:  <20130505043432.38a7f696.freebsd@edvax.de>
In-Reply-To: <1367689417.83465.YahooMailNeo@web120006.mail.ne1.yahoo.com>
References:  <1367689417.83465.YahooMailNeo@web120006.mail.ne1.yahoo.com>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Sat, 4 May 2013 10:43:37 -0700 (PDT), Michael Bird wrote:
> 
> Hi List,
> 
> There is a rather curious problem that I have, which I haven't encountered before.
> I make regular backups of my packages and put them onto an external usb drive,
> which is mounted read/write via sysutils/fusefs-ntfs.

Just to make sure I do understand what you're doing: You are
saving files from a FreeBSD UFS file system to a "NTFS" file
system? That's not a good thing(TM)(R)(C)!

Explanation: THe UFS file system and this "NTFS" differ in
how file names may be constructed (valid characters) and what
file attributes are supported. The best idea to backup (!)
files from FreeBSD to a different disk is to format it with
UFS. If you _need_ to use "NTFS", make a "containter" that
will preserve file attributes. You can easily do this with
dump (and later on use restore), but also with tar (should
be sufficient).

The problem you're describing sounds familiar. It has been
discussed on this list some time ago. Maybe check the archives
to read that discussion thread.



> Now these backups don't exist no more and at the same time they are there.

Sorry, those don't qualify as backups (in what this term means).
They can be considered an imcomplete or damaged copy (even if
it's just a question of "are there, but cannot be accessed").



> That 
> is to say, upon issuing ls and/or rm on the command line I get rather strange results. 
> Here are some of my outputs:
> 
> 
> mike@machine1:/mnt/Programs/FreeBSD/91binaries/packages % ls
> [a long list that has been cut out]
> zip-3.0.tbz
> mike@machine1:/mnt/Programs/FreeBSD/91binaries/packages % ls zip-3.0.tbz 
> ls: zip-3.0.tbz: No such file or directory

You can use fstat for that file to obtain more information:

	$ fstat /mnt/Programs/FreeBSD/91binaries/packages/zip-3.0.tbz



> Some have files that (don't) exist have i-nodes and some haven't:
> 
> mike@machine1:/mnt/Programs/FreeBSD/91binaries/packages % ls -i zip-3.0.tbz 
> ls: zip-3.0.tbz: No such file or directory
> mike@machine1:/mnt/Programs/FreeBSD/91binaries/packages % ls -i linux-f10-tiff-3.8.2.tbz 
> 2469 linux-f10-tiff-3.8.2.tbz

I assume this is because "NTFS" does not have a compatible understanding
of inodes...



> Running rm on the folder I get "No such file or directory" for every single entry:
> 
> mike@machine1:/mnt/Programs/FreeBSD/91binaries/packages % rm *
> [a long list that has been cut out]
> rm: linux-f10-tiff-3.8.2.tbz: No such file or directory

This is correct when you consider that the required inode structures
for the file system access haven't been properly constructed.



> Yet again some of the files can be test via gzip and some can't:
> 
> mike@machine1:/mnt/Programs/FreeBSD/91binaries/packages % gzip -t linux-f10-tiff-3.8.2.tbz
> mike@machine1:/mnt/Programs/FreeBSD/91binaries/packages % echo $?
> 0
> mike@machine1:/mnt/Programs/FreeBSD/91binaries/packages % gzip -t zip-3.0.tbz 
> gzip: can't stat: zip-3.0.tbz: No such file or directory
> mike@machine1:/mnt/Programs/FreeBSD/91binaries/packages %

So the "backup" (in this case: quotation marks deserved, sorry) is
highly inconsistent. But gzip provides an important information:

	gzip: can't stat: zip-3.0.tbz: No such file or directory

Cannot stat. The file status cannot be determined. This means the
file system cannot be used as intended.



> Looks like the this part of the file system is corrupt. I also booted the drive up under 
> Windows and got the same result. The files are there, but can't be read, overwritten
> or deleted.

The whole "NTFS" is corrupt. You should not use this for backups,
or at least use an "encapsulation" as suggested. This "NTFS" is
known to be easily affected by errors, and it does not provide
the required compatibility to store FreeBSD backups.



> What does the list say about the above mentioned?

Do not use "NTFS", especially not for backups of FreeBSD. :-)


-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?20130505043432.38a7f696.freebsd>