0

One of the annoyances/features of Windows is that once a file is opened nothing can be done on the file directory entry itself. i.e. you cannot move the file somewhere else while it is open etc. This is useful to make sure some operations do not go bonkers and have some predictability.

However, a lot of UNIX tools disassociate the file directory entry from the i-node entry and allow you to move/delete/rename a file and the existing file handle that points to the old name still works. I was wondering if WSL's implementation also has the same property?

Improve this question
3
  • 1
    I think I remember an MSDN dev blog post about WinNT not really having any such restrictions internally – the "locking" behavior was just deliberately kept in the API for compatibility.
    – grawity_u1686
    Commented May 28, 2022 at 18:33
  • right and a lot of apps still use the older APIs too.
    – Archimedes Trajano
    Commented May 28, 2022 at 18:38
  • the older APIs ?? CreateFile() (what most real programmers use.. yes to open files too) and OpenFile() are how you create and open files in windows since Windows 95 (and before) and are still the one and only way to do it today. All user mode file access calls map to them I believe.
    – Señor CMasMas
    Commented May 30, 2022 at 6:42

2 Answers 2

Reset to default
2

Windows and Linux work in very similar ways - both allow renaming an open file with no problem. The file's contents remain exclusively locked by the locking process, even though it may not have a name any more.

Linux however allows deleting an open file, which Windows doesn't allow. This is a design decision by the Windows developers, since the underlying file-system structure does allow it.

As regarding opening and creating a file, the Windows API has a parameter that defines the type of access permitted to other processes. By default, creating a file gives the creating process exclusive access, while opening an existing file does not give exclusive access. However, these defaults can easily be overridden by optional parameters of the function.

WSL system calls are in the end mapped to Windows function calls, so they obey the same rules (depending on how the mapping was programmed). There is nothing that WSL can do that is not possible with Windows API, as in the end it's Windows API that does the job, and (in the most prevalent case) it's the same NTFS file-tables that are operated upon.

Improve this answer
0

I'm not quite sure how to reproduce/test the scenario you have in mind, but the answer is likely going to differ between WSL1 and WSL2, and also between files stored "in" WSL and those on the Windows drive.

  • WSL1:

    • Files in WSL:

      WSL1 uses VolFs, an overlay filesystem designed by Microsoft that allows the WSL1 files to co-exist on the NTFS drive. It's most likely that, because these files are ultimately accessed through the same NTFS API, that they will be subject to the same limitations as other Windows files.

    • Files on Windows drives:

      WSL1 uses DrvFs for files stored on Windows drives. Again, since these files are ultimately accessed through NTFS, they are likely going to be subject to the same limitations.

  • WSL2:

    • Files in WSL:

      WSL2 creates a virtual SDD (a Hyper-V .vhdx file) which is formatted with an ext4 filesystem. As a virtual drive, inside WSL2, all file access will be through the Linux kernel. The VHD is kept open at all times in Windows, but virtual read/write/delete operations inside WSL2 will be autonomous.

      When accessing WSL files from Windows, the 9P network filesystem is used. Additional locking may be in use when the file is being accessed with 9P.

    • Files on Windows Drives:

      WSL2 also uses 9P to access files on Windows drives from inside WSL2 instances. Again, a combination of NTFS limitations and 9P locking is likely used in this scenario.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .