mstorsjo added a comment. In D146490#4209495 <https://reviews.llvm.org/D146490#4209495>, @aganea wrote:
> Fair enough. There are several choices forward: either we mark the issue as > "Will Not Fix" or I can try only scoping this patch to only keep the handle > for network drives/paths. Any other suggestions? I also kinda share the sentiment that keeping handles open might be problematic - the cure is worse than the disease. I wouldn't quite start throwing in the towel quite yet though... While the docs say that the ID only is stable as long as the handles are open (except for NTFS where it's an implementation detail), it's also stable enough for FAT (as long as nobody is defragmenting the drive while the process is open); at least stable enough for compiler/linker use, but possibly not for long running processes like clangd. It might not even be strictly necessary for all network drives; out of 4 tested cases, it seemed to behave fine (stable enough at least) with a Linux Samba mount and a drive shared from VMWare Fusion, while Remote Desktop folder sharing (and allegedly VirtualBox although I haven't tried that) exhibit the issue. But I don't know of any immediate way of identifying the problematic cases either... Another potential band-aid solution is to simply hash the pathnames for such drives. We won't get the desired effect of correctly identifying the same individual file via different pathnames (hardlinks/symlinks), but we would at least have a stable representation of a file. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D146490/new/ https://reviews.llvm.org/D146490 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
