Compression utility should indicate status of compression in filename

Question

Compression utility should indicate status of compression in filename

FruityWelsh opened this issue 4 years ago · 12 comments

Since it seems renaming it had no negative effects to the compression, it should instead be renamed by the compression utility to indicate status. I.E.: file.compressing[*---] and with progress file.compressing[**--]. It should also check what the current main section of the name is and use that when renaming, allowing for a user to rename the first part without losing it on the next name update.

The option of simply hiding it, violates the principle of doing something when a user does something to indicate action and makes canceling via deletion a power user task instead of a normal option.

The option of a pop-up has two downsides:

It could get lost
If it forced top level, it could get in the way of use on what could be a background task for the user

My personal preference for a filename based option is also so that I could potentially use this via cli instead of monitoring the file size changes.

glibg10b commented 4 years ago

👍2

Answer 1 · 2021-12-06T18:04:59.000Z

Is it easy to write a program that changes the name with high frequency like this? If so that is an interesting idea.

Answer 2 · 2021-12-06T18:42:04.000Z

The [] characters won't work on some file systems though, right?

Answer 3 · 2021-12-07T14:07:56.000Z

The [] characters won't work on some file systems though, right?

hmm I was concerned for special characters in cli use, but I was not aware of filesystems that would lack support for them, do you have any examples?

Answer 4 · 2021-12-07T18:00:05.000Z

As I mentioned earlier on reddit, it's rather more intuitive to show a progress bar on unfinished zip files (or half-copied files for that matter) to inform the users that the zipping/copying progress is not finished.

Possibly looks like this:

Answer 5 · 2021-12-07T20:03:27.000Z

do you have any examples?

I just looked it up. Popular examples of "problematic" filesystems are FAT12/16/32 not supporting [] and NTFS not supporting *. Here is a more comprehensive list.

Answer 6 · 2021-12-08T05:21:46.000Z

@rossbridger It's being considered, but it'd be hard to implement (https://youtu.be/ENBu9_xTrWU?t=877)

Answer 7 · 2021-12-08T05:22:12.000Z

Oops, didn't mean to close

Answer 8 · 2021-12-08T15:38:28.000Z

The square brackets will 1000% cause problems in any script where you so much as look in the directory where that file exists.

Answer 9 · 2021-12-08T15:44:52.000Z

@tjkrobertson Good scripts escape/quote filenames (otherwise spaces would also break them)

Answer 10 · 2021-12-08T16:12:50.000Z

Last I checked, `ls` doesn't return a list of quoted files. If you use that on a file with square brackets in the filename, POSIX-compliant shells will bug out because they're the symbol that denotes an if statement.

…

On Wed, Dec 8, 2021, at 10:45 AM, glibg10b wrote: @tjkrobertson <https://github.com/tjkrobertson> Good scripts escape/quote filenames (otherwise spaces would also break them) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#32 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AU6CYJCDBOAQ73EP2M5MNU3UP54P7ANCNFSM5JPG6GFQ>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

Answer 11 · 2021-12-09T05:04:38.000Z

@tjkrobertson That's what wildcards are for, they automatically escape weird characters and spaces