Re: fstat weirdness

["Pierre A. Humblet" <Pierre dot Humblet at ieee dot org>]

Corinna Vinschen wrote:
> 
> On Tue, Jun 03, 2003 at 11:43:30AM -0400, Pierre A. Humblet wrote:
> > Around line 182 of fhandler-disk_file.cc there is this strange
> > comment:
> >   /* Check a special case here. If ntsec is ON it happens
> >      that a process creates a file using mode 000 to disallow
> >      other processes access. In contrast to UNIX, this results
> >      in a failing open call in the same process. Check that
> >      case. */
> > I have looked up cvs and the ChangeLogs to find its origin,
> > without success.
> 
> Tue Feb  6 15:04:00 2001  Corinna Vinschen <corinna@vinschen.de>
> 
>         * syscalls.cc (stat_worker): Add a check for the special case when
>         a process creates a file using mode 000 using ntsec.
> 
> I found the reason for the change in my mail archive. A snippet from
> a PM to Chris:
> 
> === SNIP ===
> > I've found a serious problem in tar-1.13.18-2 in latest which didn't
> > occur in tar-1.13-2. Symlinks aren't correctly created if a ".." is
> > part of the link.
> [...]
> I've found the reason for that. The file which is created as a
> placeholder for the symlink is created with mode 000. The later
> lstat is no problem when running UNIX but it's a problem on
> Cygwin. lstat tries to open the file to do a GetFileInformationByHandle
> call. This open fails when running ntsec.[...]
> === SNAP ===
> 
> > The comment is strange because this section runs after a query_open
> > has failed for access reasons. Such failure ONLY happens if there is
> > no access_allowed ACE (even without any rights) for the current user
> > nor one of his/her groups. Thus it can't happen when the file was
> > created by Cygwin (as implied in the comment), because Cygwin
> > always adds ACEs for the owner and for everyone (even with mode 000).
> 
> Since the original problem occured more than two years ago, it's not
> obvious if we still need it.  Checking the above situation with tar
> might help.

Wow, there was time where it was done up in syscalls.cc

Things seem to be just fine, see below. 
The weird thing is that tar first does an fstat while the file is opened, 
and then an lstat after closing it. Both are OK.

 1515  171515 [main] tar 417 open: open (tarit2/printtoken.c, 0xA01)
  252  180455 [main] tar 417 alloc_sd: uid 11054, gid 12655, attribute 0
  285  197914 [main] tar 417 open: 4 = open (tarit2/printtoken.c, 0xA01)
  522  205706 [main] tar 417 fhandler_disk_file::fstat_helper: 0 = fstat (, 0x22FC78)
st_atime=3EDCCCFA st_size=0, st_mode=0x8000, st_ino=19999, sizeof=96
  359  206836 [main] tar 417 close: 0 = close (4)

  897  220941 [main] tar 417 lstat64: entering
  246  221187 [main] tar 417 normalize_posix_path: src tarit2/printtoken.c
  243  232238 [main] tar 417 fhandler_disk_file::fstat_helper: 0 = fstat (, 0x22FD88)
st_atime=3EDCCCFA st_size=0, st_mode=0x8000, st_ino=19999, sizeof=96

  322  240394 [main] tar 417 unlink: 0 = unlink (tarit2/printtoken.c)
 4023  286480 [main] tar 417 symlink: 0 = symlink (../../printtoken.c, tarit2/printtoken.c)

Uhm..., why did it fail in the past? Let's fgrep stat_worker...

2001-06-14  Egor Duda  <deo@logos-m.ru>

	* fhandler.cc (fhandler_base::open): Set win32 access flags to 0, when
	requested.
	* fhandler.h: New status flag FH_QUERYOPEN.
	(fhandler::get_query_open): New function.
	(fhandler::set_query_open): Ditto.
	* syscalls.cc (stat_worker): Request query-only open mode.

There was no query_open yet...
I will remove the special code.

Pierre