GNU bug report logs - #28440
fts_info is set to FTS_DP for an Unreadable directory instead of FTS_DNR on s390x

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 28440 in the body.
You can then email your comments to 28440 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Prajakta Bhatekar <prajakta_bhatekar <at> persistent.com>
To: "bug-coreutils <at> gnu.org" <bug-coreutils <at> gnu.org>
Subject: fts_info is set to FTS_DP for an Unreadable directory instead of
 FTS_DNR on s390x
Date: Wed, 13 Sep 2017 03:56:00 +0000

[Message part 1 (text/plain, inline)]

I have a piece of code that checks for access to a non-root user to perform a recursive chown operation on a directory with its child directory having 0 permissions(all permission bits set to zero)

It uses the` fts_info` flags of FTSENT structure returned by fts_read().For s390x architecture(big endian), it is seen that the value of fts_info for the unreadable directory is set as 6 (FTS_DP) corresponding to postorder directory instead of 6 (FTS_DNR) which is an Unreadable directory . For x86 architecture (little endian), expected behaviour is observed as fts_info is FTS_DNR.

Architecture: s390x
Version: 8.25-2ubuntu2

Here is the test code


os::mkdir("one/two"));

os::chmod("one/two", 0));

// Recursive chown should now fail to fully recurse due to

// the lack of permission on "one/two".

EXPECT_ERROR(os::chown(uid.get(), gid.get(), "one", true));

EXPECT_ERROR(os::chown(uid.get(), gid.get(), "one/two", true));


I am using fts_info for the above test as shown below

char* path_[] = {const_cast<char*>(path.c_str()), nullptr};



  FTS* tree = ::fts_open(

      path_, FTS_NOCHDIR | FTS_PHYSICAL, nullptr);



  if (tree == nullptr) {

    return ErrnoError();

  }



  FTSENT *node;

  while ((node = ::fts_read(tree)) != nullptr) {

    switch (node->fts_info) {



Best,



Prajakta Bhatekar <prajakta_bhatekar <at> persistent.com>







DISCLAIMER
==========
This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.

[Message part 2 (text/html, inline)]

Message #8 received at 28440 <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
To: Prajakta Bhatekar <prajakta_bhatekar <at> persistent.com>, 28440 <at> debbugs.gnu.org
Subject: Re: bug#28440: fts_info is set to FTS_DP for an Unreadable directory
 instead of FTS_DNR on s390x
Date: Mon, 29 Oct 2018 19:24:00 -0600

tags 28440 notabug
close 28440
stop

(triaging old bugs)

Hello,

On 2017-09-12 9:56 p.m., Prajakta Bhatekar wrote:
> I have a piece of code that checks for access to a non-root user to perform a recursive chown operation on a directory with its child directory having 0 permissions(all permission bits set to zero)
> 
> It uses the` fts_info` flags of FTSENT structure returned by fts_read().For s390x architecture(big endian), it is seen that the value of fts_info for the unreadable directory is set as 6 (FTS_DP) corresponding to postorder directory instead of 6 (FTS_DNR) which is an Unreadable directory . For x86 architecture (little endian), expected behaviour is observed as fts_info is FTS_DNR.
> 

It seems your message was lost and not replied to in a year.
Sorry about that.

From your question it appears you are asking a programming question,
but this is the GNU coreutils mailing list - used to report
bugs in GNU coreutils programs (e.g. sort/head/tail/cut/dd).

As such, I'm closing this as "not a bug".

regards,
 - assaf

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.