Skip Montanaro <skip@pobox.com> writes: > What about a networked environment? If machine A without large file support > mounts an NFS directory from machine B that does support large files, what > should a program running on A see if it attempts to stat a large file? I would have to read the specs to answer this question correctly, but I believe the answer would go like this: case 1: Machine A only supports NFSv2, which does not support large files. When machine A accesses a large file on machine B (through the NFS GETATTR operation), it will see a truncated file. Notice that the exact behaviour depends on the NFSv2 implementation on machine B. case 2: Machine A supports NFSv3, and the client NFS implementation correctly recognizes the large file. Now, you say "A has no large file support". That could either mean that the syscalls don't support that, or that the C library doesn't support that. If the kernel does not support it, it may be that it does not define EOVERFLOW, either. Most likely, you will again see the truncated value. > Sounds like the EOVERFLOW thing would come in handy here. It's not our choice whether the operating system reports EOVERFLOW, or a truncated file. My guess is that you likely see a truncated file, but you would need to specify a precise combination of (client C lib, client OS, wire NFS version, server OS) to find out what really happens. My guess is that if the system is not aware of large files, it likely won't work "correctly" when it sees one, with Python having no way to influence the outcome. Regards, Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4