-
Notifications
You must be signed in to change notification settings - Fork 129
store lock files in temporary directory #273
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
motivation: local file system store lock files next to the file being locked and never cleans them up changes: * add a tempDirectory to FileSystem protocol * update determineTempDirectory to use tempDirectory from localFileSystem * move logic to handle local file system locks to FileLock and call it from localFileSystem * expose an API on FileLock to create local file system locks, which by default uses the temp directory to store lock files, using the file-to-lock path and name to construct the lock file name * move local file system lock logic to use the new FileLock API * add tests rdar://86644116
swiftlang/swift-package-manager#3962 @swift-ci please test |
throw FileSystemError(.notDirectory, lockFilesDirectory) | ||
} | ||
// use the parent path to generate unique filename in temp | ||
var lockFileName = (resolveSymlinks(fileToLock.parentDirectory).appending(component: fileToLock.basename)).components.joined(separator: "_") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's somewhat of a risk of overflow here since most operating systems / file systems have a much shorter file name limit than path limit. I don't know if that will be an issue in practice — an alternate approach to consider here might be to hash all the but the last n components of the path, which should still be indicative of what the lock file refers to.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we can also re-root the path into temp a potential solution. would that be better than what we have here now?
motivation: local file system store lock files next to the file being locked and never cleans them up changes: * add a tempDirectory to FileSystem protocol * update determineTempDirectory to use tempDirectory from localFileSystem * move logic to handle local file system locks to FileLock and call it from localFileSystem * expose an API on FileLock to create local file system locks, which by default uses the temp directory to store lock files, using the file-to-lock path and name to construct the lock file name * move local file system lock logic to use the new FileLock API * add tests rdar://86644116
motivation: local file system store lock files next to the file being locked and never cleans them up changes: * add a tempDirectory to FileSystem protocol * update determineTempDirectory to use tempDirectory from localFileSystem * move logic to handle local file system locks to FileLock and call it from localFileSystem * expose an API on FileLock to create local file system locks, which by default uses the temp directory to store lock files, using the file-to-lock path and name to construct the lock file name * move local file system lock logic to use the new FileLock API * add tests rdar://86644116
motivation: local file system store lock files next to the file being locked and never cleans them up
changes:
rdar://86644116