search

Fortran-FOSS-Programmers / ford

Automatically generates FORtran Documentation from comments within the code.
https://forddocs.readthedocs.io
GNU General Public License v3.0
407 stars 133 forks source link

copytree fails on some filesystems #128

Closed aradi closed 8 years ago

aradi commented 8 years ago

Although, it is not Fords fault :wink: , Ford does not work on our NFS file system. Runing it results in

Creating HTML documentation...
Traceback (most recent call last):
  File "/home/aradi/sync/laptop/dftb_devel/ford/ford/output.py", line 429, in copytree
    shutil.copystat(src, dst)
  File "/home/aradi/local/opt/virtualenv/sphinx/lib/python3.4/shutil.py", line 213, in copystat
    _copyxattr(src, dst, follow_symlinks=follow)
  File "/home/aradi/local/opt/virtualenv/sphinx/lib/python3.4/shutil.py", line 153, in _copyxattr
    os.setxattr(dst, name, value, follow_symlinks=follow_symlinks)
OSError: [Errno 22] Invalid argument: './doc/css'

The culprit is Pythons os.setxattr() routine, which also fails on our NFS when applied to directories. Copying the content to a local directory resolves the problem, but it would be probably better to have a workaround in Ford.

I've written a possible workaround using the os.walk() method and copying content manually. As far as I can see, it should do everything what Ford uses so far, but I could be wrong. If you think it suits, I can make an formal merge request or you can just merge it directly.

cmacmackin commented 8 years ago

I've switched over to your approach. I just changed it to ensure that any files which get copied will show up with a new date on them. This is necessary in order to keep certain build systems from rerunning FORD when it's not necessary (Issue #55).

aradi commented 8 years ago

Cool! Probably I am overseeing something, but I am pretty convinced, that the proposed solution already does that implicitly. As it uses shutil.copy(), it should not copy any metadata, so the copied files should always have the correct date (the moment, when the copy statement was invoked), shouldn't they? I have the feeling, that the explicit touch() call in your older version was only necessary, because you copied the files together with their metadata (which included the time of their last modification).

cmacmackin commented 8 years ago

Looking at your version I had thought that too, but when I tested it out I found that it created files with the date of their originals. Anyway, the easiest thing was just to insert the touch calls to be safe.

On 09/05/16 10:20, Bálint Aradi wrote:

Cool! Probably I am overseeing something, but I am pretty convinced, that the proposed solution already does that implicitly. As it uses |shutil.copy()|, it should not copy any metadata, so the copied files should always have the correct date (the moment, when the copy statement was invoked), shouldn't they? I have the feeling, that the explicit |touch()| call in your older version was only necessary, because you copied the files together with their metadata (which included the time of their last modification).

— You are receiving this because you modified the open/close state. Reply to this email directly or view it on GitHub https://github.com/cmacmackin/ford/issues/128#issuecomment-217816026

Chris MacMackin cmacmackin.github.io http://cmacmackin.github.io