Re: prefer local files to network connections
Wait, does this mean 'tar -cf host:file ...' will overwrite the local file 'host:file' only if that file already exists? That sounds confusing. I was only thinking about reading (tf, xf). I agree it would be weird on creation. suggesting to me that I should put 'export TAR_OPTIONS=--force-local' into my .profile, much as I dislike having environment variables Exactly my feelings (x2) as well. One possible minor improvement would be to say that file names starting with "/" or with "./" are never remote, I believe that's already the case (thankfully). $ touch foo:bar $ tar xf ./foo:bar tar: This does not look like a tar archive ... As for the --remote option idea ... certainly I'm all for making force-local the default. As soon as possible :). I wonder how many people actually use the hostname:path feature. Besides, I gather from the code, the Amanda project. (Would be interesting to see if their code actually relies on it.) --best, karl.
Re: prefer local files to network connections
On 2024-01-30 11:02, Paul Eggert wrote: Perhaps it's time to evolve tar in the direction that it should have gone back in the 1980s. That is, we add an option --remote to require remote interpretation of file names, and warn if a remote file name is used without --remote. Eventually we can make --remote the default. (There may be a better option name than "--remote"; we can look at other programs for ideas.) Oops, I meant to write "Eventually we can make --force-local the default." (Did I say this area was confusing? :-)
Re: prefer local files to network connections
On 2024-01-30 10:57, Sam James wrote: The whole thing is bizarre and continues to catch people by surprise: https://lists.gnu.org/archive/html/bug-tar/2017-05/msg2.html. Yes, if I could go back decades in time I would say "don't implement it that way -- add an option instead!" What 'tar' currently does is a recipe for confusion. Perhaps it's time to evolve tar in the direction that it should have gone back in the 1980s. That is, we add an option --remote to require remote interpretation of file names, and warn if a remote file name is used without --remote. Eventually we can make --remote the default. (There may be a better option name than "--remote"; we can look at other programs for ideas.)
Re: prefer local files to network connections
Karl Berry writes: > I suggest that tar check if a file exists before trying to make a > network connection. This would eliminate the need for --force-local in > (I expect) most cases. As in: > > $ touch foo:bar > $ tar xf foo:bar > tar: Cannot connect to foo: resolve failed > > whereas I'd prefer/expect the usual error: > tar: This does not look like a tar archive > > > Also, since the whole idea of tar making network connections is highly > non-traditional, I also suggest making an environment variable that > turns off the network stuff completely. TAR_NO_NETWORK or some > such. Since --force-local eliminates the possibility of using > traditional no-dash options, an alias does not suffice. It is not > desirable to make wrapper scripts for something as basic as tar. Just > an idea/wish ... --thanks, karl. The whole thing is bizarre and continues to catch people by surprise: https://lists.gnu.org/archive/html/bug-tar/2017-05/msg2.html.
Re: prefer local files to network connections
> On Tue, 30 Jan 2024 19:09:45 +0100, Sergey Poznyakoff said: > > > I suggest that tar check if a file exists before trying to make a > > network connection. This would eliminate the need for --force-local in > > (I expect) most cases. As in: > > Nice idea. I'll implement it. Is there a potential security risk where someone could create that file in the cwd of an important tar command and then capture/control the tar file contents? __Martin
Re: prefer local files to network connections
On 2024-01-30 10:09, Sergey Poznyakoff wrote: Hi Karl! I suggest that tar check if a file exists before trying to make a network connection. This would eliminate the need for --force-local in (I expect) most cases. As in: Nice idea. I'll implement it. Wait, does this mean 'tar -cf host:file ...' will overwrite the local file 'host:file' only if that file already exists? That sounds confusing. The 'host:file' convention is already confusing, as this bug report is suggesting to me that I should put 'export TAR_OPTIONS=--force-local' into my .profile, much as I dislike having environment variables affect standard utilities. I'm not sure it's a good idea to make the convention even more confusing. One possible minor improvement would be to say that file names starting with "/" or with "./" are never remote, even if they have colons in them. Though this likely wouldn't address the glitch that triggered Karl's bug report, at least it'd make it easier to write portable scripts that don't access the network unexpectedly.
Re: prefer local files to network connections
Hi Karl! > I suggest that tar check if a file exists before trying to make a > network connection. This would eliminate the need for --force-local in > (I expect) most cases. As in: Nice idea. I'll implement it. > Also, since the whole idea of tar making network connections is highly > non-traditional, I also suggest making an environment variable that > turns off the network stuff completely. TAR_NO_NETWORK or some > such. There's no need for that, you can just do: export TAR_OPTIONS=--force-local That will disable network connections. And it doesn't disturb short or traditional options, either. Regards, Sergey
