summaryrefslogtreecommitdiffstats
path: root/llvm/include/llvm/Support/FileSystem.h
Commit message (Collapse)AuthorAgeFilesLines
* Fix uninitialized variable warnings in directory_entry default constructor. NFCISimon Pilgrim2019-10-041-3/+3
| | | | llvm-svn: 373742
* [Support] Improve readNativeFile(Slice) interfacePavel Labath2019-08-221-13/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: There was a subtle, but pretty important difference between the Slice and regular versions of this function. The Slice function was zero-initializing the rest of the buffer when the read syscall returned less bytes than expected, while the regular function did not. This patch removes the inconsistency by making both functions *not* zero-initialize the buffer. The zeroing code is moved to the MemoryBuffer class, which is currently the only user of this code. This makes the API more consistent, and the code shorter. While in there, I also refactor the functions to return the number of bytes through the regular return value (via Expected<size_t>) instead of a separate by-ref argument. Reviewers: aganea, rnk Subscribers: kristina, Bigcheese, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66471 llvm-svn: 369627
* [llvm-objcopy] Don't change permissions of non-regular output filesFangrui Song2019-07-111-4/+6
| | | | | | | | | | | | | | | | | | | | | | There is currently an EPERM error when a regular user executes `llvm-objcopy a.o /dev/null`. Worse, root can even change the mode bits of /dev/null. Fix it by checking if the output file is special. A new overload of llvm::sys::fs::setPermissions with FD as the parameter is added. Users should provide `perm & ~umask` as the parameter if they intend to respect umask. The existing overload of llvm::sys::fs::setPermissions may be deleted if we can find an implementation of fchmod() on Windows. fchmod() is usually better than chmod() because it saves syscalls and can avoid race condition. Reviewed By: jakehehrlich, jhenderson Differential Revision: https://reviews.llvm.org/D64236 llvm-svn: 365753
* [Support] Move llvm::MemoryBuffer to sys::fs::file_tReid Kleckner2019-07-101-8/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: On Windows, Posix integer file descriptors are a compatibility layer over native file handles provided by the C runtime. There is a hard limit on the maximum number of file descriptors that a process can open, and the limit is 8192. LLD typically doesn't run into this limit because it opens input files, maps them into memory, and then immediately closes the file descriptor. This prevents it from running out of FDs. For various reasons, I'd like to open handles to every input file and keep them open during linking. That requires migrating MemoryBuffer over to taking open native file handles instead of integer FDs. Reviewers: aganea, Bigcheese Reviewed By: aganea Subscribers: smeenai, silvas, mehdi_amini, hiraditya, steven_wu, dexonsmith, dang, llvm-commits, zturner Tags: #llvm Differential Revision: https://reviews.llvm.org/D63453 llvm-svn: 365588
* [Support] Add fs::getUmask() function and change fs::setPermissionsAlex Brachet2019-06-281-1/+12
| | | | | | | | | | | | | | | | Summary: This patch changes fs::setPermissions to optionally set permissions while respecting the umask. It also adds the function fs::getUmask() which returns the current umask. Reviewers: jhenderson, rupprecht, aprantl, lhames Reviewed By: jhenderson, rupprecht Subscribers: sanaanajjar231288, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63583 llvm-svn: 364621
* [llvm-objcopy] Make .build-id linking atomicJake Ehrlich2019-03-181-2/+23
| | | | | | | | This change makes linking into .build-id atomic and safe to use. Some users under particular workflows are reporting that this races more than half the time under particular conditions. llvm-svn: 356404
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [Support] Remove error return value from one overload of fs::make_absolutePavel Labath2019-01-161-4/+1
| | | | | | | | | | | | | | | | | | | | | | Summary: The version of make_absolute which accepted a specific directory to use as the "base" for the computation could never fail, even though it returned a std::error_code. The reason for that seems to be historical -- the CWD flavour (which can fail due to failure to retrieve CWD) was there first, and the new version was implemented by extending that. This removes the error return value from the non-CWD overload and reimplements the CWD version on top of that. This enables us to remove some dead code where people were pessimistically trying to handle the errors returned from this function. Reviewers: zturner, sammccall Subscribers: hiraditya, kristina, llvm-commits Differential Revision: https://reviews.llvm.org/D56599 llvm-svn: 351317
* [Support/FileSystem] Add sub-second precision for atime/mtime of ↵Argyrios Kyrtzidis2018-11-261-4/+25
| | | | | | | | | | | | | | | | | | | | sys::fs::file_status on unix platforms Summary: getLastAccessedTime() and getLastModificationTime() provided times in nanoseconds but with only 1 second resolution, even when the underlying file system could provide more precise times than that. These changes add sub-second precision for unix platforms that support improved precision. Also add some comments to make sure people are aware that the resolution of times can vary across different file systems. Reviewers: labath, zturner, aaron.ballman, kristina Reviewed By: aaron.ballman, kristina Subscribers: lebedev.ri, mgorny, kristina, llvm-commits Differential Revision: https://reviews.llvm.org/D54826 llvm-svn: 347530
* [FileSystem] Add expand_tilde functionJonas Devlieghere2018-11-131-0/+6
| | | | | | | | | | | | In D54435 there was some discussion about the expand_tilde flag for real_path that I wanted to expose through the VFS. The consensus is that these two things should be separate functions. Since we already have the code for this I went ahead and added a function expand_tilde that does just that. Differential revision: https://reviews.llvm.org/D54448 llvm-svn: 346776
* [Support] Listing a directory containing dangling symlinks is not an error.Sam McCall2018-10-011-27/+9
| | | | | | | | | | | | | | Summary: Reporting this as an error required stat()ing every file, as well as seeming semantically questionable. Reviewers: vsk, bkramer Subscribers: mgrang, kristina, llvm-commits, liaoyuke Differential Revision: https://reviews.llvm.org/D52648 llvm-svn: 343460
* [Support] sys::fs::directory_entry includes the file_type.Kristina Brooks2018-09-121-21/+34
| | | | | | | | | | | | | | | | This is available on most platforms (Linux/Mac/Win/BSD) with no extra syscalls. On other platforms (e.g. Solaris) we stat() if this information is requested. This will allow switching clang's VFS to efficiently expose (path, type) when traversing a directory. Currently it exposes an entire Status, but does so by calling fs::status() on all platforms. Almost all callers only need the path, and all callers only need (path, type). Patch by sammccall (Sam McCall) Differential Revision: https://reviews.llvm.org/D51918 llvm-svn: 342089
* [Support] NFC: Fix docstring in FileSystem.h.Reka Kovacs2018-08-171-1/+1
| | | | llvm-svn: 340063
* [Support] NFC: Allow modifying access/modification times independently in ↵Jordan Rupprecht2018-08-131-1/+9
| | | | | | | | | | | | | | | | | sys::fs::setLastModificationAndAccessTime. Summary: Add an overload to sys::fs::setLastModificationAndAccessTime that allows setting last access and modification times separately. This will allow tools to use this API when they want to preserve both the access and modification times from an input file, which may be different. Also note that both the POSIX (futimens/futimes) and Windows (SetFileTime) APIs take the two timestamps in the order of (1) access (2) modification time, so this renames the method to "setLastAccessAndModificationTime" to make it clear which timestamp is which. For existing callers, the 1-arg overload just sets both timestamps to the same thing. Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D50521 llvm-svn: 339628
* [ThinLTO] Update ThinLTO cache file atimes when on WindowsAndrew Ng2018-07-041-0/+3
| | | | | | | | | | | | | | | | | | ThinLTO cache file access times are used for expiration based pruning and since Vista, file access times are not updated by Windows by default: https://blogs.technet.microsoft.com/filecab/2006/11/07/disabling-last-access-time-in-windows-vista-to-improve-ntfs-performance This means on Windows, cache files are currently being pruned from creation time. This change manually updates cache files that are accessed by ThinLTO, when on Windows. Patch by Owen Reynolds. Differential Revision: https://reviews.llvm.org/D47266 llvm-svn: 336276
* Fix Wdocumentation compiler warning. NFCI.Simon Pilgrim2018-06-301-1/+1
| | | | llvm-svn: 336049
* Add a flag to FileOutputBuffer that allows modification.Zachary Turner2018-06-281-0/+6
| | | | | | | | | | | | | FileOutputBuffer creates a temp file and on commit atomically renames the temp file to the destination file. Sometimes we want to modify an existing file in place, but still have the atomicity guarantee. To do this we can initialize the contents of the temp file from the destination file (if it exists), that way the resulting FileOutputBuffer can have only selective bytes modified. Committing will then atomically replace the destination file as desired. llvm-svn: 335902
* LTO: Keep file handles open for memory mapped files.Peter Collingbourne2018-06-131-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On Windows we've observed that if you open a file, write to it, map it into memory and close the file handle, the contents of the memory mapping can sometimes be incorrect. That was what we did when adding an entry to the ThinLTO cache using the TempFile and MemoryBuffer classes, and it was causing intermittent build failures on Chromium's ThinLTO bots on Windows. More details are in the associated Chromium bug (crbug.com/786127). We can prevent this from happening by keeping a handle to the file open while the mapping is active. So this patch changes the mapped_file_region class to duplicate the file handle when mapping the file and close it upon unmapping it. One gotcha is that the file handle that we keep open must not have been created with FILE_FLAG_DELETE_ON_CLOSE, as otherwise the operating system will prevent other processes from opening the file. We can achieve this by avoiding the use of FILE_FLAG_DELETE_ON_CLOSE altogether. Instead, we use SetFileInformationByHandle with FileDispositionInfo to manage the delete-on-close bit. This lets us remove the hack that we used to use to clear the delete-on-close bit on a file opened with FILE_FLAG_DELETE_ON_CLOSE. A downside of using SetFileInformationByHandle/FileDispositionInfo as opposed to FILE_FLAG_DELETE_ON_CLOSE is that it prevents us from using CreateFile to open the file while the flag is set, even within the same process. This doesn't seem to matter for almost every client of TempFile, except for LockFileManager, which calls sys::fs::create_link to create a hard link from the lock file, and in the process of doing so tries to open the file. To prevent this change from breaking LockFileManager I changed it to stop using TempFile by effectively reverting r318550. Differential Revision: https://reviews.llvm.org/D48051 llvm-svn: 334630
* Add a file open flag that disables O_CLOEXEC.Zachary Turner2018-06-081-1/+5
| | | | | | | | | | | O_CLOEXEC is the right default, but occasionally you don't want this. This is especially true for tools like debuggers where you might need to spawn the child process with specific files already open, but it's occasionally useful in other scenarios as well, like when you want to do some IPC between parent and child. llvm-svn: 334293
* Fix Wdocumentation warning for unknown param. NFCI.Simon Pilgrim2018-06-081-2/+0
| | | | llvm-svn: 334291
* Expose a single global file open function.Zachary Turner2018-06-071-14/+64
| | | | | | | | | This one allows much more flexibility than the standard openFileForRead / openFileForWrite functions. Since there is now just one "real" function that does the work, all other implementations simply delegate to this one. llvm-svn: 334246
* [FileSystem] Split up the OpenFlags enumeration.Zachary Turner2018-06-071-22/+88
| | | | | | | | | | | | | | | | | This breaks the OpenFlags enumeration into two separate enumerations: OpenFlags and CreationDisposition. The first controls the behavior of the API depending on whether or not the target file already exists, and is not a flags-based enum. The second controls more flags-like values. This yields a more easy to understand API, while also allowing flags to be passed to the openForRead api, where most of the values didn't make sense before. This also makes the apis more testable as it becomes easy to enumerate all the configurations which make sense, so I've added many new tests to exercise all the different values. llvm-svn: 334221
* [FileSystem] Remove OpenFlags param from several functions.Zachary Turner2018-06-051-4/+2
| | | | | | | | | | | | There was only one place in the entire codebase where a non default value was being passed, and that place was already hidden in an implementation file. So we can delete the extra parameter and all existing clients continue to work as they always have, while making the interface a bit simpler. Differential Revision: https://reviews.llvm.org/D47789 llvm-svn: 334046
* [Support] Add functions that operate on native file handles on Windows.Zachary Turner2018-06-041-0/+48
| | | | | | | | | | | | | | | | | | | | Windows' CRT has a limit of 512 open file descriptors, and fds which are generated by converting a HANDLE via _get_osfhandle count towards this limit as well. Regardless, often you find yourself marshalling back and forth between native HANDLE objects and fds anyway. If we know from the getgo that we're going to need to work directly with the handle, we can cut out the marshalling layer while also not contributing to filling up the CRT's very limited handle table. On Unix these functions just delegate directly to the existing set of functions since an fd *is* the native file type. It would be nice, very long term, if we could convert most uses of fds to file_t. Differential Revision: https://reviews.llvm.org/D47688 llvm-svn: 333945
* [Support] Add docs for 'openFileFor{Write,Read}'Brian Gesiak2018-05-111-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add documentation for the LLVM Support functions `openFileForWrite` and `openFileForRead`. The `openFileForRead` parameter `RealPath`, in particular, I think warranted some explanation. In addition, make the behavior of the functions more consistent across platforms. Prior to this patch, Windows would set or not set the result file descriptor based on the nature of the error, whereas Unix would consistently set it to `-1` if the open failed. Make Windows consistently set it to `-1` as well. Test Plan: 1. `ninja check-llvm` 2. `ninja docs-llvm-html` Reviewers: zturner, rnk, danielmartin, scanon Reviewed By: danielmartin, scanon Subscribers: scanon, danielmartin, llvm-commits Differential Revision: https://reviews.llvm.org/D46499 llvm-svn: 332075
* Remove @brief commands from doxygen comments, too.Adrian Prantl2018-05-011-54/+54
| | | | | | | | | | | | | | | | | This is a follow-up to r331272. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done https://reviews.llvm.org/D46290 llvm-svn: 331275
* IWYU for llvm-config.h in llvm, additions.Nico Weber2018-04-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | See r331124 for how I made a list of files missing the include. I then ran this Python script: for f in open('filelist.txt'): f = f.strip() fl = open(f).readlines() found = False for i in xrange(len(fl)): p = '#include "llvm/' if not fl[i].startswith(p): continue if fl[i][len(p):] > 'Config': fl.insert(i, '#include "llvm/Config/llvm-config.h"\n') found = True break if not found: print 'not found', f else: open(f, 'w').write(''.join(fl)) and then looked through everything with `svn diff | diffstat -l | xargs -n 1000 gvim -p` and tried to fix include ordering and whatnot. No intended behavior change. llvm-svn: 331184
* s/LLVM_ON_WIN32/_WIN32/, llvmNico Weber2018-04-291-5/+5
| | | | | | | | | | | | | | LLVM_ON_WIN32 is set exactly with MSVC and MinGW (but not Cygwin) in HandleLLVMOptions.cmake, which is where _WIN32 defined too. Just use the default macro instead of a reinvented one. See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev. No intended behavior change. This moves over all uses of the macro, but doesn't remove the definition of it in (llvm-)config.h yet. llvm-svn: 331127
* [llvm-cov] Prevent llvm-cov from hanging when a symblink doesn't exist.Max Moroz2018-04-051-6/+25
| | | | | | | | | | | | | | | | | | | | Summary: Previous code hangs indefinitely when trying to iterate through a symbol link file that points to an non-exist directory. This change fixes the bug to make the addCollectedPath function exit ealier and print out correct warning messages. Patch by Yuke Liao (@liaoyuke). Reviewers: Dor1s, vsk Reviewed By: vsk Subscribers: bruno, mgrang, llvm-commits Differential Revision: https://reviews.llvm.org/D44960 llvm-svn: 329338
* Changed createTemporaryFile without FD to actually create a file.Ilya Biryukov2018-03-191-3/+28
| | | | | | | | | | | | | | | | | | | | | Summary: This commit changes semantics of createUniqueFile and createTemporaryFile variants that do not return file descriptors. Previously they only checked if files exist, therefore being subject to race conditions. Now they will create an empty file to avoid them. Functions that do not create a file are now called getPotentiallyUniqueTempFileName and getPotentiallyUniqueFileName. Reviewers: klimek, bkramer, krasimir, JDevlieghere, espindola Reviewed By: klimek Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D36827 llvm-svn: 327851
* [Support] Add WriteThroughMemoryBuffer.Zachary Turner2018-03-081-3/+8
| | | | | | | | | | | This is like MemoryBuffer (read-only) and WritableMemoryBuffer (writable private), but where the underlying file can be modified after writing. This is useful when you want to open a file, make some targeted edits, and then write it back out. Differential Revision: https://reviews.llvm.org/D44230 llvm-svn: 327057
* Call FlushFileBuffers on output files.Zachary Turner2018-02-151-0/+2
| | | | | | | | | | | | There is a latent Windows kernel bug, the exact trigger conditions are not well understood, which can cause a file to be correctly written, but unable to be correctly read. The workaround appears to be simply calling FlushFileBuffers. Differential Revision: https://reviews.llvm.org/D42925 llvm-svn: 325274
* Use FILE_FLAG_DELETE_ON_CLOSE for TempFile on windows.Rafael Espindola2017-11-281-2/+1
| | | | | | We won't see the temp file no more. llvm-svn: 319137
* Add an F_Delete flag.Rafael Espindola2017-11-281-1/+5
| | | | | | For now this only changes the handle Access. llvm-svn: 319121
* Add OpenFlags to the create(Unique|Temporary)File interfaces.Rafael Espindola2017-11-271-22/+24
| | | | | | | This will allow a future F_Delete flag to be specified when we want the file to be automatically deleted on close. llvm-svn: 319117
* Convert another use of createUniqueFile to TempFile::create.Rafael Espindola2017-11-161-0/+3
| | | | | | | This one requires a new small feature in TempFile: the ability to keep the temporary file with the temporary name. llvm-svn: 318458
* Add a move assignment operator to TempFile. NFC.Rafael Espindola2017-11-141-0/+1
| | | | llvm-svn: 318122
* Create a TempFile class.Rafael Espindola2017-11-131-0/+35
| | | | | | | | | | | | | | | This just adds a TempFile class and replaces the use in FileOutputBuffer with it. The only difference for now is better error handling. Followup work includes: - Convert other user of temporary files to it. - Add support for automatically deleting on windows. - Add a createUnnamed method that returns a potentially unnamed file. It would be actually unnamed on modern linux and have a unknown name on windows. llvm-svn: 318069
* Support: Have directory_iterator::status() return ↵Peter Collingbourne2017-10-101-58/+83
| | | | | | | | | | | | | | | | | | FindFirstFileEx/FindNextFile results on Windows. This allows clients to avoid an unnecessary fs::status() call on each directory entry. Because the information returned by FindFirstFileEx is a subset of the information returned by a regular status() call, I needed to extract a base class from file_status that contains only that information. On my machine, this reduces the time required to enumerate a ThinLTO cache directory containing 520k files from almost 4 minutes to less than 2 seconds. Differential Revision: https://reviews.llvm.org/D38716 llvm-svn: 315378
* Support: Rewrite Windows implementation of sys::fs::rename to be more POSIXy.Peter Collingbourne2017-10-061-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current implementation of rename uses ReplaceFile if the destination file already exists. According to the documentation for ReplaceFile, the source file is opened without a sharing mode. This means that there is a short interval of time between when ReplaceFile renames the file and when it closes the file during which the destination file cannot be opened. This behaviour is not POSIX compliant because rename is supposed to be atomic. It was also causing intermittent link failures when linking with a ThinLTO cache; the ThinLTO cache implementation expects all cache files to be openable. This patch addresses that problem by re-implementing rename using CreateFile and SetFileInformationByHandle. It is roughly a reimplementation of ReplaceFile with a better sharing policy as well as support for renaming in the case where the destination file does not exist. This implementation is still not fully POSIX. Specifically in the case where the destination file is open at the point when rename is called, there will be a short interval of time during which the destination file will not exist. It isn't clear whether it is possible to avoid this using the Windows API. Differential Revision: https://reviews.llvm.org/D38570 llvm-svn: 315079
* [Support] mapped_file_region: store size as size_tRoman Lebedev2017-09-271-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Found when testing stage-2 build with D38101. ``` In file included from /build/llvm/lib/Support/Path.cpp:1045: /build/llvm/lib/Support/Unix/Path.inc:648:14: error: comparison 'uint64_t' (aka 'unsigned long') > 18446744073709551615 is always false [-Werror,-Wtautological-constant-compare] if (length > std::numeric_limits<size_t>::max()) { ~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ``` `size_t` is `uint64_t` here, apparently, thus any `uint64_t` value always fits into `size_t`. Initial patch was to use some preprocessor logic to not check if the size is known to fit at compile time. But Zachary Turner suggested using this approach. Reviewers: Bigcheese, rafael, zturner, mehdi_amini Reviewed by (via email): zturner Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D38132 llvm-svn: 314312
* [Support] Remove getPathFromOpenFD, it was unusedReid Kleckner2017-08-041-6/+0
| | | | | | | | | | | | | | Summary: It was added to support clang warnings about includes with case mismatches, but it ended up not being necessary. Reviewers: twoh, rafael Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D36328 llvm-svn: 310078
* Move Object format code to lib/BinaryFormat.Zachary Turner2017-06-071-55/+0
| | | | | | | | | | | | This creates a new library called BinaryFormat that has all of the headers from llvm/Support containing structure and layout definitions for various types of binary formats like dwarf, coff, elf, etc as well as the code for identifying a file from its magic. Differential Revision: https://reviews.llvm.org/D33843 llvm-svn: 304864
* Add functionality to cvtres to parse all entries in res file.Eric Beckmann2017-05-201-1/+1
| | | | | | | | | | | Summary: Added the new modules in the Object/ folder. Updated the llvm-cvtres interface as well, and added additional tests. Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D33180 llvm-svn: 303480
* [Support] Avoid UB in sys::fs::perms::operator~. NFC.Ahmed Bougacha2017-04-261-1/+3
| | | | | | | This was exposed in r297945 and r301220: the intermediate complement is a 32-bit value, and casting it to 'perms' invokes UB. llvm-svn: 301373
* [Support] Fill the file_status struct with link count.Zachary Turner2017-03-201-11/+16
| | | | | | Differential Revision: https://reviews.llvm.org/D31110 llvm-svn: 298326
* Add a function to MD5 a file's contents.Zachary Turner2017-03-201-0/+11
| | | | | | | | | | | | | | | In doing so, clean up the MD5 interface a little. Most existing users only care about the lower 8 bytes of an MD5, but for some users that care about the upper and lower, there wasn't a good interface. Furthermore, consumers of the MD5 checksum were required to handle endianness details on their own, so it seems reasonable to abstract this into a nicer interface that just gives you the right value. Differential Revision: https://reviews.llvm.org/D31105 llvm-svn: 298322
* [Support] Add support for getting file system permissions on Windows and ↵James Henderson2017-03-161-2/+24
| | | | | | | | | | | | | | | | | | implement sys::fs::set/getPermissions to work with them This change adds support for functions to set and get file permissions, in a similar manner to the C++17 permissions() function in <filesystem>. The setter uses chmod on Unix systems and SetFileAttributes on Windows, setting the permissions as passed in. The getter simply uses the existing status() function. Prior to this change, status() would always return an unknown value for the permissions on a Windows file, making it impossible to test the new function on Windows. I have therefore added support for this as well. On Linux, prior to this change, the permissions included the file type, which should actually be accessed via a different member of the file_status class. Note that on Windows, only the *_write permission bits have any affect - if any are set, the file is writable, and if not, the file is read-only. This is in common with what MSDN describes for their behaviour of std::filesystem::permissions(), and also what boost::filesystem does. The motivation behind this change is so that we can easily test behaviour on read-only files in LLVM unit tests, but I am sure that others may find it useful in some situations. Reviewers: zturner, amccarth, aaron.ballman Differential Revision: https://reviews.llvm.org/D30736 llvm-svn: 297945
* Reverting r297617 because it broke some bots:Aaron Ballman2017-03-131-41/+20
| | | | | | http://bb.pgr.jp/builders/cmake-llvm-x86_64-linux/builds/49970 llvm-svn: 297618
* Add support for getting file system permissions and implement ↵Aaron Ballman2017-03-131-20/+41
| | | | | | | | sys::fs::permissions to set them. Patch by James Henderson. llvm-svn: 297617
OpenPOWER on IntegriCloud