java.nio.file.FileSystemException: /path/to/bandcamp/downloads Value too large for defined data type

[yakkonaut]

Repost of https://framagit.org/Ezwen/bandcamp-collection-downloader/-/issues/31

Ezwen- love this tool! have been running the v2020-12-15 flawlessly once a week with the same command to pull updated stuff from my collection to my home media server. This week I started getting this error for each worker:

Exception in thread "pool-1-thread-4" java.io.UncheckedIOException: java.nio.file.FileSystemException: /mnt/usbraid/share/media/bandcamp2: Value too large for defined data type
	at java.base/java.nio.file.Files$2.hasNext(Files.java:3776)
	at java.base/java.util.Iterator.forEachRemaining(Iterator.java:132)
	at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
	at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
	at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
	at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913)
	at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
	at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578)
	at bandcampcollectiondownloader.BandcampCollectionDownloader.manageDownloadPage(BandcampCollectionDownloader.kt:211)
	at bandcampcollectiondownloader.BandcampCollectionDownloader.access$manageDownloadPage(BandcampCollectionDownloader.kt:15)
	at bandcampcollectiondownloader.BandcampCollectionDownloader$downloadAll$task$1.run(BandcampCollectionDownloader.kt:114)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
	at java.base/java.lang.Thread.run(Thread.java:832)
Caused by: java.nio.file.FileSystemException: /mnt/usbraid/share/media/bandcamp2: Value too large for defined data type
	at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:100)
	at java.base/sun.nio.fs.UnixException.asIOException(UnixException.java:120)
	at java.base/sun.nio.fs.UnixDirectoryStream$UnixDirectoryIterator.readNextEntry(UnixDirectoryStream.java:168)
	at java.base/sun.nio.fs.UnixDirectoryStream$UnixDirectoryIterator.hasNext(UnixDirectoryStream.java:198)
	at java.base/java.nio.file.Files$2.hasNext(Files.java:3774)
	... 13 more

I tried some debugging but I'm not sure how to pursue farther. I'm using the release build, and not super familiar with kotlin or gradle so I'm not building from source. I can figure out how though if necessary. To verify it wasn't an issue with the filesystem I tried pointing it to a different folder to "redownload" my whole collection and got that error on the first worker. I also created a separate bandcamp account and added some stuff to it to try a new account to make sure it wasn't an issue with one of the files in my collection. This is happening for any worker I try to spawn from Ubuntu on an odroid xu4

root@odroid:/opt/bandcamp-collection-downloader# java --version
openjdk 14.0.2 2020-07-14
root@odroid:/opt/bandcamp-collection-downloader# uname -a
Linux odroid 5.4.109-220 #1 SMP PREEMPT Fri Apr 2 10:28:49 EDT 2021 armv7l armv7l armv7l GNU/Linux

[yakkonaut]

I tried figuring out where to start debugging this today and I don't even know... my next idea is to just try running from a different system. Worried it's an openjdk issue :(

[Ezwen]

Hi there! Thanks for the report, quite a mysterious one though :)

After a quick search, it seems this could be related to the fact that you are running the tool on a 32 bits system. I do not know yet while the tool would ask your system to manipulate values outside its range, but I'll keep thinking.

[Ezwen]

I believe to investigate we would need the tool to be much more verbose. I've been thinking for a while to add a debug verbose level, this could be a good opportunity :)

[Ezwen]

Also, sorry for not answering to the issue reported on Framagit. I do not know why I did not receive any notification email, hm.

[yakkonaut]

All good! I thought Framagit was repo of record, but I saw issues here too so thought maybe I was wrong. The 32/64bit issue might be it, but I also can't see what could possibly be counting so high. My collection has just over 1300 items in it... is there something that might be counting lots of objects per collection item? It would take a pretty big blowup to break a 28bit int or whatever the max is in 32 bit java.

[yakkonaut]

Anecdotal evidence... just nfs mounted the drive to another machine and kicked off my downloader script and it appears to be working- so same account, same folder, same cached download db, just different host executing the bandcamp downloader process.

openjdk 11.0.11 2021-04-20
OpenJDK Runtime Environment 18.9 (build 11.0.11+9)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.11+9, mixed mode, sharing)

But... if I'm reading that right, I'm on an OLDER openjdk, that was built more recently?

[Ezwen]

Thanks for your experiments, that can prove useful :)

Meanwhile I'm investigating the trace. The problem happens line 211 of BandcampCollectionDownloader.java, thus this line:

bandcamp-collection-downloader/src/main/kotlin/bandcampcollectiondownloader/core/BandcampCollectionDownloader.kt

Line 211 in 0420ce0

if (Files.isDirectory(downloadFolderPath) && !Files.isDirectory(artistFolderPath)) {

So it crashes when the JVM asks the OS for information about a specific path.

Then, looking at the code of UnixDirectoryStream.java also mentioned in the trace:

https://code.yawk.at/java/11/java.base/sun/nio/fs/UnixDirectoryStream.java#165

        // Returns next entry (or null)
        private Path readNextEntry() {
            assert Thread.holdsLock(this);

            for (;;) {
                byte[] nameAsBytes = null;

                // prevent close while reading
                readLock().lock();
                try {
                    if (isOpen()) {
                        nameAsBytes = readdir(dp);
                    }
                } catch (UnixException x) {
                    IOException ioe = x.asIOException(dir);
                    throw new DirectoryIteratorException(ioe);
                } finally {
                    readLock().unlock();
                }
…

We can see that line 168, which is responsible for the exception, is IOException ioe = x.asIOException(dir);

Which means that the initial exception could come from this line of the same file:

nameAsBytes = readdir(dp);

… which could mean that the name of a file or folder, once translated into bytes during this process, becomes too large for your 32bits system, and thus make it crash. Maybe an artist or release name that is really long, or using special characters? (no idea whether weird unicode could make this value bigger) Maybe a path that is too long, because of too many subfolders?

And if that is the cause of the problem, the next question would be how to solve it… For now I have no idea, since the root problem is too low level, but I'll keep thinking 😄