lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAO3qy=GqsSvx4b=YcFbifDGpbD8pp70wmQj6vRRZ5gtU7Y7DGQ@mail.gmail.com>
Date:   Sun, 12 Feb 2017 20:35:16 +0300
From:   Artem Blagodarenko <artem.blagodarenko@...gate.com>
To:     "Theodore Ts'o" <tytso@....edu>
Cc:     linux-ext4@...r.kernel.org
Subject: Re: [PATCH] debugfs: increase inode reference count after link

Hello Theodore,

Thank you for explanation and sorry I misunderstand "link" command. I
don't want to add "link" version that increase reference count. I
added some stings to "expect" file and expect fsck will warn about
this reference count. This is fine for debug purpose.

Best regares,
Artem Blagodarenko.


On Tue, Jan 31, 2017 at 6:48 AM, Theodore Ts'o <tytso@....edu> wrote:
> On Fri, Jan 20, 2017 at 07:53:42PM +0300, Artem Blagodarenko wrote:
>> Inode reference count is not increased after debugfs link command.
>> This leads to inconsistent file system state.
>
> That was deliberate.  Originally the "link" and "unlink" commands were
> designed as a low-level command that didn't change the link count.
> There are *many* commands in debugfs that can lead to inconsistent
> file system state.  In fact, the original raison d'être of debugfs was
> to create corrupted file systems to test e2fsck.  :-)
>
> The "rm" command is user-friendly command that I added later which
> decrements the link count and deallocates the blocks if the link count
> goes to zero.
>
> I never got around to adding a user-friendly 'ln' command which
> creates the directory entry and also increments the link count.
> That's mainly because no one has really needed or wanted that
> functionality.  Or at least, no one has requested it up until now.
>
> If you really want it, probably the best thing to do would be unalias
> the "link" and "ln" commands, and make the "ln" command the
> user-friendly command that works like the /bin/ln command.
>
> Cheers,
>
>                                                 - Ted



-- 
Artem Blagodarenko Ph.D.· SW Developer on my.seagate.com
Seagate Technology, LLC
www.seagate.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ