I'm synching an entire hard drive between local and GDrive with links (Symlinks) included. This drive has a symlink which gives an error in Windows that says "The file or directory is corrupted or unreadable." so I can't make any read operations with it thus I'm excluding it from the sync operation.
Now, I have added an entry to the exclusion command -and this entry is the aforementioned symbolic link- but rclone is ignoring this and is still trying to sync that "file". Other exclusions work as usual, it seems rclone is ignoring exclusions that point to symlinks when we use --links.
What is your rclone version (output from rclone version)
1.57.0
Which cloud storage system are you using? (eg Google Drive)
Google Drive
The command you were trying to run (eg rclone copy /tmp remote:tmp)
That's what I did because if I shared the debug log with the original local path it would have been much larger. I changed the path to the parent dir of the directory where the file is located
But does it really needs to read the file? I mean, I don't know the code obviously so maybe I'm saying something pretty stupid but if we locate in Windows, to know the contents of a directory Windows doesn't need to read all the files that said directory contains, running dir I can get the file listing without getting any error because -as far as I understand- it doesn't read any file.
Even so, I have other two files that doesn't have the same but a CRC error (drive has faulty sectors) and I have excluded them with success, why I'm not getting the same results (an error trying to read them) with those files if rclone needs to read them before excluding them?
Doesn't dir reads the metadata? Even file explorers read metadata and I can view the symlink metadata just fine. This is what it shows when I run the command:
18/11/2021 17:16 <SYMLINK> FILENAME.EXT [..]
But also, why does it needs to read the metadata before excluding it? With --exclude the only thing it needs to know is the file path/name, as long as that matches the exclude param then it just needs to ignore it no matter what metadata it contains, isn't it?
Yeah, it seems so.
As I understand you first told me it needs to read the metadata of every item. It can read the metadata of the symbolic link because other software can.
Then you told me it needs access to the directory path to view its content, it can access the path and its content can be listed because other software can.
You can’t exclude something you don’t have access to. By read, I mean read the directory and file metadata and not actually reading the file.
Rclone should be able to access the directory and to read the metadata of the symlink, why wouldn't it be able to if other software can do it?
What no software can do is resolve the link nor can the symlink be deleted/renamed/opened, none of which rclone should be trying to do and for what I read in the log it is trying to read the symlink I'm guessing to resolve it.
The problem that I've reported is that rclone is not excluding symlinks no matter if rclone can or not resolve the link.
If I tree the directory using rclone I get:
rclone tree --human --color --modtime --links "E:\dir1\subdir1\subdir2"
2021/11/26 22:23:56 ERROR : FILENAME.ext.rclonelink: Failed to read link size: readlink \\?\E:\dir1\subdir1\subdir2\FILENAME.ext: El archivo o directorio está dañado o es ilegible.
├── [ Nov 18 17:16] FILENAME.ext.rclonelink
But it also tries to read the link and I don't get why when all that it's showing are the dates and the filenames, it should be enough for rclone to know that it is a symbolic link and whatever it is pointing to has nothing to do with the listing. I'm misunderstanding something here?
Ahhhhh I think I got why it is failing. It seems rclone is trying to resolve the links to store the target in a text file and get the rclonelink file, that's why when I add --size to the tree command it reports sizes for all the other symbolic links except the one that is corrupted that says 0
