Can not move files anywhere beyond first levlel of directories.

[TildeSlashC0re]

Installation method Docker (running the latest AzuraCast git-master 1145911358c8e4ad7e60d9bfaa16fb9c80a3ef44)

Host OS (for Docker installations) Debian Stretch [9.0]

Describe the bug

root
├── dir-one
│   ├── subdir-one
│   └── subdir-two
├── dir-two
└── file.wav

Moving the file.wav from:

• the root-directory to dir-one :heavy_check_mark:
• the root-directory to dir-two :heavy_check_mark:
• dir-one to dir-two :heavy_check_mark:
• dir-two to subdir-one or subdir-two :stop_sign:
• dir-one to subdir-one or subdir-two :stop_sign:
• root-directory to subdir-one or subdir-two :stop_sign:

and very interestingly moving file.wav from:

• subdir-one or subdir-two to dir-two :heavy_check_mark:

Another quirk is that I am able to directly upload into the subdir-directories, but not able to delete files inside of them.

To Reproduce

1. Go to Music-Files
2. Create New Folder
3. Go to Folder
4. Create another New Folder
5. Try moving any file into the last folder you created
6. see absolutely nothing happen

Expected behavior

File operations should succeed beyond the first level of directories.

Relevant Logs

(fully aware how this sounds) I wasn't able to find anything meaningful in the docker-compose logs -f

Screenshots

Device(s):

• Device: Desktop
• OS: Debian Buster [10.0]
• Browser: chrome
• Version: 72

Additional context

[TildeSlashC0re]

Here are logs from --log-level DEBUG

web_1       | 172.23.0.1 - - [09/Feb/2019:08:59:32 +0000] "POST /station/1/files/batch HTTP/1.0" 200 143 "https://<domain>/station/1/files" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.81 Safari/537.36" "xx.xx.xx.xx"
web_1       | 172.23.0.1 - - [09/Feb/2019:08:59:32 +0000] "POST /station/1/files/list HTTP/1.0" 200 709 "https://<domain>/station/1/files" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.81 Safari/537.36" "xx.xx.xx.xx"
web_1       | 172.23.0.1 - - [09/Feb/2019:08:59:32 +0000] "GET /api/nowplaying/1 HTTP/1.0" 200 3331 "https://<domain>/station/1/profile" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36" "xx.xx.xx.xx"
stations_1  | 2019/02/09 08:59:37 [<a-different-station!>_next_song:3] Finished with "/usr/local/share/icecast/web/error.mp3".
stations_1  | 2019/02/09 08:59:37 [<a-different-station!>_next_song:3] Prepared "/usr/local/share/icecast/web/error.mp3" (RID 28).

the POST request to /station/1/files/batchseems to be answered with a 200 ... the effect is .. well none

:/

[BusterNeece]

@Vaalyn Since you worked on the "move file" dialog and controller code, want to take a look at this?

[Vaalyn]

@SlvrEagle23 Looked into this and could reproduce it locally. There is a problem with the path that is being sent in the AJAX request. This is what was submitted in my test: directory: Dir-layer-1/Dir-layer-1/Dir-layer-2. The Dir-layer-1 should only be once in the path.

The problem stems from the data-path attribute on the SELECT button. There the path is already wrong for sub-directories. I submitted a fix for this with PR #1164.

~What I could not reproduce is the deletion problem. I could successfully delete files from the root directory, Dir-layer-1, Dir-layer-1/Dir-layer-2 and Dir-layer-1/Dir-layer-2/Dir-layer-3.~

I could reproduce the deletion error now. When uploading a file and then trying to delete it this error is sent in the AJAX response: "The given value "" does not represent a valid number.". Stacktrace in response.

[Vaalyn]

The deletion will fail on the newly uploaded file because the file is not yet indexed by the sync task. When uploading a file in one tab and then triggering the media sync task in another tab then the deletion directly works.

[BusterNeece]

@TildeSlashC0re @Vaalyn I've reworked the upload process to make it so that rather than re-listing after every single successful upload, it waits until all the uploads are complete and processed and then triggers a reload that flushes the Redis cache for Flysystem, which resolves a number of issues around process timing and cache invalidation.