Tag Info

New answers tagged

0

ext4 since kernel 3.8 supports this: it can store (very) small files within the inode, as described in the filesystem layout documentation. Other filesystems support this on Linux too, or variants of the idea; for example Btrfs stores small files in the parent extent.


0

As Wumpus Q. Wumbley pointed out, there was either a corrupted byte or a whopper of a co-incidence. I decided to bite the bullet and delete the file, which went smoothly with no apparent damage to the surrounding files.


0

The fat32 filesystem has no notion of ownership or permissions. The man page for mount lists these options that help make it look closer to what Unix users expect: uid=value and gid=value Set the owner and group of all files. (Default: the uid and gid of the current process.) umask=value Set the umask (the bitmask of the permissions ...


2

Since this is a little bit too long for a comment here it goes... There are two things that got me intrigued: First of all, /dev/sda and /dev/sdb are two different physical drives, otherwise we would be talking about /dev/sda1 and /dev/sda2. So if we are talking about different physical drives their performances may vary. Second, in case this info is ...


2

Your file system is very unlikely to be corrupted. Ext4fs, like most Unix file systems supports sparse files, i.e. files which have some of their blocks not backed by any physical media and which blocks by convention are returned as containing only null values (zeroes) when read. Removing a sparse file represent no specific risk, outside the fact it might ...


0

It should be "safe" to delete the file; it is a config file of sorts, telling npm what files and patterns to ignore when you are doing whatever you are doing with npm. Whether you want to delete it or not depends on you. It may be serving a useful purpose. Maybe cat it and see what it contains, and then make a judgement call from there. As @jordanm points ...


1

First, are you sure you destroyed your data? mkfs.vfat wouldn't run on a whole disk unless you specified -I flag. fdisk -l /dev/sdb outputs no partition? If so, you may have a luck with testdisk. It's a very useful tool to retrieve your deleted partitions. Just run testdisk /dev/sdb and choose "Analyze". Most of the time, it is able to find your deleted ...


0

You should just try, but with read-only methods. If the filesystem superblock is still reachable, you should be able to mount it. Then exploring the filesystem will likely creates lots of IO errors and print botched file names and contents, but that's the best you could get in any case (apart from testdisk kind of tools which scans for specific file types). ...


1

You can't mount half a partition. Half a partition isn't a container that contains half the files in the filesystem, it's basically unusable. Reaching a file requires traversing several directories and inodes which may be spread all over the partition. You can however check the beginning of the partition to see if it seems to have a valid filesystem header. ...


0

Please describe your migration in more detail. Did you grow or shrink the array, add or remove disks, or what. You don't want the error target, instead use linear and snapshot so there is a virtual layer onto which you can do experiments such as fsck, debugfs and the like without having to create yet another copy for each experiment. Use a similar method as ...


0

I had overwritten a text file (VQ1.txt) with 12 hr worth test data:( A notion that unix saves previous version of the file in text.txt~ format, made me look into folder containing the overwritten file with $ -ll Full list showed VQ1.txt~ that had my 'lost' data! $ cat VQ1.txt~ Start time at: Thu Apr 2 18:07:23 PDT 2015 User, KW: 12hrFA_OEM_HelloVoiceQ ...


2

(I know this is an old question, I came across this problem myself and got my FS back to life without ddrescue, so I'll share the expericence for anyone else encountering this) Ext filesystems store backups of the superblock -- for an occasion just like this one. First, determine the locations of the backups: mke2fs -n /dev/sdxx This is a test run (i.e. ...


1

There's another case where Birth time will be empty/zero/dash: Ext4's Inode size has to be at least 256bytes to store crtime. The problem occur if you initially created the filesystem smaller than 512MB ( the default Inode size will be 128 bytes, see /etc/mke2fs.conf and mkfs.ext4 manpage). stat -c '%n: %w' testfile testfile: - and/or stat -c '%n: %W' ...


1

That looks like file system corruption to me; to fix it, do sudo touch /forcefsck and reboot. This will force a fsck of your file systems.



Top 50 recent answers are included