FileManager Appends Additional / in file path

Does anyone have any ideas as to why I would be able to write but not read a file?

That’s not surprising. Consider this:

% # Create a file.
%
% touch test.txt
%
% # Give it /no/ permissions.
%
% chmod 000 test.txt
%
% # You can still see the file.
%
% ls test.txt 
test.txt
%
% # But you can't read it.
%
% cat test.txt 
%
% # You can, however, replace it.
%
% touch test-new.txt
% mv test-new.txt test.txt

The last step is interesting because most code that writes to a file doesn’t actually write to it. Rather, it does a ‘safe save’ operation, that writes to a temporary file and replaces the original with the temporary. That only requires write permission on the parent directory, not to the file itself.

However, this is just an example and there are many ways you can run into similar problems. File system permissions on Apple platforms are complex. I talk more about that in On File System Permissions.

I’m happy to go down this rabbit hole with you (-: To start, what platform are you on?

ps Why is your thread title “FileManager Appends Additional / in file path”? You don’t seem to mention that aspect of this issue anywhere in your question.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thank you!

That is very interesting, I didn't know about the 'safe save' operation! As far as the title of my post goes, I accidentally published before I had a chance to update the title of the post. While debugging this issue with my team, we found that my file manager adds an additional / in the path name - it was the only difference between my experience on my machine and my teammates' experiences on their respective machines, so it was the only lead I had for a while.

I'm working on the iOS platform on a framework. This scenario arose while running tests that touch the FileManager - without revealing too much sensitive information, the test in question grabs a file in the project and uses the file manager to convert the file into data so that we can create an object from that data. Every time we try and call the 'fileManager.contents(atPath:)' method, it crashes because it is nil despite being able to see the file in its expected location in Finder.

When we first discovered that the only difference between my scenario and my co-workers scenario was an additional errant / in the path name, we tried just removing the additional slash but it still returned nil for the file.