Compression utility should indicate status of compression in filename

[FruityWelsh]

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:

1. It could get lost
2. 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.

[magnus-ISU]

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

[NicoWeio]

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

[FruityWelsh]

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?

[rossbridger]

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:

[NicoWeio]

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.

[glibg10b]

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

[glibg10b]

Oops, didn't mean to close

[tjkrobertson]

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

[glibg10b]

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

[tjkrobertson]

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 https://github.com/glibg10b/ltt-linux-challenge-issues/issues/32#issuecomment-988929701, 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.

[glibg10b]

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

[glibg10b]

1. Temp file names now have a .part suffix
2. Temp files are now hidden
3. .part files don't open directly