mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

fix temp filename

Browse source 
Was not putting it inside the temp dir, but next to it!

This was just wrong, and it led to a longer filename that desired being
used, leading to some bug reports.
This commit is contained in:
Joey Hess 2015-12-06 16:50:37 -04:00
parent 6e71094e7d
commit 2936153fc4
Failed to extract signature
6 changed files with 43 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

2
doc/bugs/20151116_tests_fail_on_OS_X.mdwn
View file

@ -36,3 +36,5 @@ FAIL (0.29s)
(This could be due to a bug in git-annex, or an incompatability
with utilities, such as git, installed on this system.)
```
> [[fixed|done]] --[[Joey]]

12
doc/bugs/20151116_tests_fail_on_OS_X/comment_2_59f7803b9a9ee939a8a50605fe5c4682._comment Normal file
View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="joey"
subject="""comment 2"""
date="2015-12-06T20:02:49Z"
content="""
Ok, this involves where the test suite is run.
The addurl test adds `file://`pwd`/somefile`, and that will create a file
with a name like `_home_you_sub_dir_path_here_somefile`. Which can easily
exceed filename length limits of 255 bytes.
There was indeed a reversion in addurl's handling of that.
"""]]

2
doc/bugs/importfeed_fails_on_createSymbolicLink___40__but_ln_-s_works__41__.mdwn
View file

@ -46,3 +46,5 @@ Debian amd64 unstable package 5.20151116-1.
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
That’s just a little hiccup in, up to now, various months of merry use! ;-)
> [[fixed|done]] --[[Joey]]

24
doc/bugs/importfeed_fails_on_createSymbolicLink___40__but_ln_-s_works__41__/comment_1_c831256a081b181a121910aca3151e45._comment Normal file
View file

@ -0,0 +1,24 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2015-12-06T19:50:59Z"
content="""
I can reproduce this.
symlink("../.git/annex/objects/fK/9M/URL--http&c%%mvod.lvlt.rtve.es%resour-39e58395b01e2385d46bade56127cfc4/URL--http&c%%mvod.lvlt.rtve.es%resour-39e58395b01e2385d46bade56127cfc4", ".git/annex/misctmp/Documentos_RNE___Coss\303\255o_y_la_Casona_de_Tudanca__refugio_de_la_cultura_espa\303\261ola_entre_las_monta\303\261as_de_Cantabria___28_08_15.mp3.0Documentos_RNE___Coss\303\255o_y_la_Casona_de_Tudanca__refugio_de_la_cultura_espa\303\261ola_entre_las_monta\303\261as_de_Cantabria___28_08_15.mp3") = -1 ENAMETOOLONG (File name too long)
The problem is not the length of the link target, which is only 170
characters and will work on any OS. The basename of the symlink
being created is pretty long, 294 characters, and that's the
cause of the failure.
joey@darkstar:~>ln -s /dev/null $(perl -e 'print ("a" x 294)')
ln: failed to create symbolic link ‘aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa’ -> ‘/dev/null’: File name too long
The limit is 255 characters in a single path component (`pathconf _PC_NAME_MAX`).
So, the issue is caused by the rss feed having a long title for this
item.
And this used to work; it's a recent reversion. Fixing.
"""]]