Revert "FileLock encounters a runtime error when the path of the locked file is long"

[compnerd]

Reverts #277

[compnerd]

@swift-ci please test

[compnerd]

This regressed the windows build: https://ci-external.swift.org/job/oss-swift-windows-toolchain-x86_64-vs2019/619/console

[abertelrud]

Thanks @compnerd. What is the Windows way to get NAME_MAX? This does need to be fixed, just reverting it won't fix the underlying issue, so I'm keen to see how to modify the fix.

[compnerd]

I understand that this needs to be fixed but reverting it and fixing it with the ability to properly work through this seems better (unless you have a solution off the top of your head). I don't think that there is a good equivalence. There is no limit on an arc, only on the full path (MAX_PATH).

[compnerd]

@abertelrud - could we take the windows approach globally? Just limit the full path rather than the arc?

[abertelrud]

@abertelrud - could we take the windows approach globally? Just limit the full path rather than the arc?

No, that's not the problem. The path is not too long, it's each individual path component that has to be limited. On Darwin etc the path max is usually 4096 or something like that (up from 1024 in earlier times) but the maximum length of an individual directory entry is usually 255 on Darwin and Linux. That's the problem here.

A better approach would normally be to try the operation and catch the error but here we need to choose the name up-front.

[abertelrud]

I understand that this needs to be fixed but reverting it and fixing it with the ability to properly work through this seems better (unless you have a solution off the top of your head). I don't think that there is a good equivalence. There is no limit on an arc, only on the full path (MAX_PATH).

Right, of course, I thought that the fix would simply be to use another constant (e.g. FILENAME_MAX as seen here https://docs.microsoft.com/en-us/cpp/c-runtime-library/filename-max?view=msvc-170).

If the length isn't a problem on windows can we just conditionalize the logic that truncates the path rather than reverting the whole thing? That seems as quick. If we must revert then I can put up that PR separately concurrently with the revert.

[abertelrud]

@compnerd I put up #281, WDYT?

[abertelrud]

Also isn't 255 UTF-16 code units the limit of a directory entry on NTFS?

[compnerd]

Yes, NTFS does limit you to 255 code units per ARC, but that is not guaranteed as the file system may be FAT :-(.

[abertelrud]

Yes, NTFS does limit you to 255 code units per ARC, but that is not guaranteed as the file system may be FAT :-(.

Right, that's true on Darwin and other OSes as well. If we do #if !os(Windows) here would that work for unblocking the build? Unfortunately there's no Windows CI that will tell me if the fix I put up compiles.

[compnerd]

Yeah, locally testing seems to indicate that it still breaks. I think that #282 is a better fix, though still incomplete as it doesn't take into account the arc limitation. However, this does seem to work to unblock the build and incidentally fixes another issue with the lock file being placed in the current working directory rather than the temp directory. I think that a follow up to enforce the arc limit would be nice, but we can do that separately.

[compnerd]

#281 + #282 are preferred over this.