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: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130505043432.38a7f696.freebsd>