How the Windows Subsystem for Linux Redirects Syscalls

Re:How the Windows Subsystem for Linux Redirects Syscalls by bigger_cheese on Wednesday June 08, 2016 @07:44PM (#11866596)

My biggest pet Peeve about Windows is the way it accesses files I'm not sure if this is a kernel or filesystem issue. But when a remote user has a file open as long as that file is open other users are prevented from updating or replacing the file. It happens all the time at my work and I know of no obvious way to work out who has the file open because as far as I can tell nothing like lsof exists.

This is probably the number one cause of me banging my head against the desk and wishing Windows behaved more like Linux.

[ Parent | on HN ]

Re:How the Windows Subsystem for Linux Redirects Syscalls by asveikau on Wednesday June 08, 2016 @09:18PM (#11866949)

What you can do while it's open is partially defined by the dwShareMode parameter in CreateFile. Unfortunately a lot of people look at the daunting documentation, shrug, and put 0 there, which is the least permissive mode. A lot of libraries do that too.

OTOH there are other limits that are not dictated by dwShareMode. Such as deleting files while handles are open - this blocks a new file with the same name from being created until all handles are closed. That's probably the worst one. There are some other crappy ones involving directory handles that I don't care to enumerate.

[ Parent | on HN ]

Re:How the Windows Subsystem for Linux Redirects Syscalls by JdeBP on Thursday June 09, 2016 @04:35PM (#11872172)

> I'm not sure if this is a kernel or filesystem issue.

It's neither. It's a common misconception. See https://news.ycombinator.com/item?id=11415366 .

[ Parent | on HN ]

Re:How the Windows Subsystem for Linux Redirects Syscalls by pjmlp on Thursday June 09, 2016 @03:41AM (#11868081)

Sane OSes don't let people modify files without permission from other users.

Windows isn't the only OS having file locking implemented at kernel level.

[ Parent | on HN ]