zsh-workers
 help / color / mirror / code / Atom feed
* Cannot write to zsystem flock's descriptor
@ 2017-03-01 10:49 Sebastian Gniazdowski
  2017-03-01 17:32 ` Bart Schaefer
  0 siblings, 1 reply; 2+ messages in thread
From: Sebastian Gniazdowski @ 2017-03-01 10:49 UTC (permalink / raw)
  To: zsh-workers

Hello,

# echo "test" > file
# zsystem flock -t 0 -f MY_FD "file"; echo $?
0
# echo a>&${MY_FD}
zsh: 11: bad file descriptor
# exec {MY_FD}>&-
(works, lock also works)

I've added debug logs to system.c and there is:

Read-write flags, 2 (O_RDWR) | 131072 (O_NOCTTY) = 131074
Before move fdflags 0
After move fdflags 0
After cloexec fdflags 1
lck.l_type RD:1, WR:3, is:3

So it looks good. When locking via "flock" util-linux program I can
write to the FD. What could it be? 

    if ((flock_fd = open(unmeta(args[0]), flags)) < 0) {

flags are like first line of debug message. I think it's open() that
matters.

-- 
  Sebastian Gniazdowski
  psprint3@fastmail.com


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Cannot write to zsystem flock's descriptor
  2017-03-01 10:49 Cannot write to zsystem flock's descriptor Sebastian Gniazdowski
@ 2017-03-01 17:32 ` Bart Schaefer
  0 siblings, 0 replies; 2+ messages in thread
From: Bart Schaefer @ 2017-03-01 17:32 UTC (permalink / raw)
  To: Sebastian Gniazdowski, zsh-workers

On Mar 1,  2:49am, Sebastian Gniazdowski wrote:
}
} # echo "test" > file
} # zsystem flock -t 0 -f MY_FD "file"; echo $?
} 0
} # echo a>&${MY_FD}
} zsh: 11: bad file descriptor

This is actually internal to zsh and has nothing to do with the state
of the descriptor itself.  See addlockfd() in utils.c and lines 3524
to 3538 (approximately) in exec.c where the redirection is handled.

When you do >&${MY_FD} that implies duplicating the descriptor to
FD 1 of the "echo" job and then closing that descriptor when echo
has finished.  Doing so with the descriptor that is being held for
flock could cause the lock to be prematurely released, so when the
table of allocated descriptors is scanned for those that are valid
as redirection targets, the FTD_FLOCK descriptors are skipped.

I don't recall whether this is a portability issue -- e.g., it could
safely be done on linux as the util-linux flock executable seems to
imply, but perhaps it can't be done elsewhere.

You can always open a different descriptor on the same file, or first
open a descriptor on the file and then flock.  Locking with flock is
advisory only -- all programs accessing the file must agree to try
flock first -- so there's no restriction on other access before or
after flock is in place.


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2017-03-01 17:33 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-01 10:49 Cannot write to zsystem flock's descriptor Sebastian Gniazdowski
2017-03-01 17:32 ` Bart Schaefer

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).