This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
Re: fstat weirdness
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